-
FlexWAN and Enhanced FlexWAN Modules Installation and Configuration Guide
-
Preface
-
FlexWAN and Enhanced FlexWAN Modules Overview
-
FlexWAN and Enhanced FlexWAN Software Features Configuration Information
-
Configuring Multiprotocol Label Switching on FlexWAN and Enhanced FlexWAN Modules
-
Configuring QoS on the FlexWAN and Enhanced FlexWAN Modules
-
Upgrading Field-Programmable Devices on the Enhanced FlexWAN Module
-
Multilink Feature Support
-
Table Of Contents
FlexWAN and Enhanced FlexWAN Software Features Configuration Information
Configuring ATM VC Access Trunk Emulation
Supported Port Adapters and Shared Port Adapters
ATM VC Access Trunk Emulation Configuration Guidelines
Configuring Distributed Network-Based Application Recognition
Configuring ACFC and PFC Support on Multilink Interfaces
Restrictions and Usage Guidelines
Configuring ACFC and PFC Support
Configuring Distributed Multilink Point-to-Point Protocol
Restrictions and Usage Guidelines
Enabling Distributed CEF Switching
Assigning an Interface to a Multilink Bundle
Disabling PPP Multilink Fragmentation
Configuring Multilink Frame Relay
Multilink Frame Relay Bundles and Bundle Links
Link Integrity Protocol Control Messages
Configuring a Multilink Frame Relay Bundle Interface
Configuring a Multilink Frame Relay Bundle Link
Verifying Multilink Frame Relay
Monitoring and Maintaining Distributed Multilink Frame Relay
Configuring Distributed Link Fragmentation and Interleaving for Frame Relay and ATM Interfaces
Related Features and Technologies
Configuring LFI Using MLP over Frame Relay
Configuring LFI Using MLP over ATM
Configuring LFI Using MLP over a Leased Line
Verifying LFI for Frame Relay, ATM, or Leased Lines
Monitoring LFI for Frame Relay, ATM, or Leased Lines
LFI over Frame Relay Configuration Example
LFI over ATM Configuration Example
LFI over Leased Line Configuration Example
Configuring Compressed Real-Time Protocol (CRTP)
Restrictions and Usage Guidelines
Changing the Number of Header Compression Connections
Configuring Voice over Frame Relay (VoFR) FRF.11 and FRF.12
Restrictions and Usage Guidelines
Configuring Dial Peer Digit Manipulation
Disabling Dial Peer Hunting on a Specific Dial Peer
Configuring a Frame Relay Map Class to Support Voice over Frame Relay Fragmentation
Configuring Voice over Frame Relay Connections
Configuring Switched Calls (User-Dialed or Auto-Ringdown)
Configuring Cisco-Trunk Permanent (Private Line) Calls
Configuring FRF.11 Trunk (Private Line) Calls
Configuring Connections for Tandem Nodes
Verifying Your Voice Connections
Configuring Frame Relay Virtual Circuit (VC) Bundling
Configuring Routed Bridged Encapsulation
RBE Restrictions and Usage Guidelines
RBE Configuration Limitation Supports Only One Remote MAC Address
Supervisor Engine and Line Card Support for RBE
ATM Port Adapters Supported for RBE
Verifying the Routed Bridged Encapsulation Configuration
OSPF over RBE Configuration Requirements
Sample OSPF over RBE Configuration
Configuring Bridging Control Protocol Support
Bridging Control Protocol Modes
Configuring Multipoint Bridging
Restrictions and Usage Guidelines
Multipoint Bridging Configurations
Configuring Multipoint Bridging for ATM Interfaces
Configuring Multipoint Bridging for Frame-Relay Interfaces
Configuring Bridged Routing Encapsulation
Bridged Routing Encapsulation Configuration Guidelines
Verifying the Bridged Routing Encapsulation Configuration
Configuring Frame Relay (RFC 1490) Bridging
Enhancements to RFC 1483 and RFC 1490 Spanning Tree Interoperability
Supported Supervisor Engines and Line Cards
Catalyst 5000 PVST BPDU Packet Format
Cisco 7200 and Cisco 7500 Routers IEEE 802.1D BPDU Frame Format
Cisco 7600 Router PVST+ BPDU Frame Format
BPDU Translation Command Line Interface Summary
Layer 2 Protocol Tunneling Topology CLI
Typical Topologies Requiring BPDU Translation
Layer 2 Protocol Tunneling Topology with a Cisco 7600, Catalyst 5500, and Catalyst 6500
Layer 2 Protocol Tunneling Topology with a Cisco 7600 and Cisco 7200
Cisco 7600 Basic Back-to-Back Scenario
Catalyst 5500 Switch and Cisco 7600 Series Routers in Back-to-Back Topology
Cisco 7600 and Cisco 7200 in Back-to-Back Topology
FlexWAN and Enhanced FlexWAN Software Features Configuration Information
Software features supported by the port adapters installed in a FlexWAN or Enhanced FlexWAN are documented in the port adapter software configuration notes or the applicable Cisco IOS software documentation.
Note
Cisco IOS Release 12.2SRA and later releases do not support the FlexWAN module or Supervisor Engine 2. These releases support the Enhanced FlexWAN module and the Sup720 and Sup32. In addition, note that Cisco IOS Release 12.2SRB introduced support for the Route Switch Processor 720 (RSP720).
The following software features supported on the port adapters that have FlexWAN-specific or Enhanced FlexWAN-specific implementations are documented in this section:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Configuring ATM VC Access Trunk Emulation
In the Metro Ethernet environment, the traffic that comes on an ATM VC can receive multiple-service VLAN traffic. The traffic for each customer-specific service VLAN is mapped to different service provider VLANs. Using the ATM VC Access Trunk Emulation feature, a single ATM VC can be used to bridge traffic to different VLANs based on the customer-specific service, represented by the dot1q ID.
Supported Port Adapters and Shared Port Adapters
•
•
Limitations and Restrictions
•
•
ATM VC Access Trunk Emulation Configuration Guidelines
•
•
•
Configuration Tasks
The VC Access Trunk Emulation configuration tasks are:
•
•
•
To configure the bridge-domain and dot1q ID on an ATM VC, use the following procedure:
In this example, multiple vlan IDs and dot1q IDs are configured:
Router# configure terminalEnter configuration commands, one per line. end with CNTL/Z.Router(config)# interface atm3/0/0.2 multipointRouter(config-if)# pvc1/21Router(config-if-atm-vc)# bridge-domain 52 dot1q 42Router(config-if-atm-vc)# bridge-domain 53 dot1q 43Router(config-if-atm-vc)# bridge-domain 54 dot1q 44Router(config-if-atm-vc)# bridge-domain 55 dot1q 45Router(config-if-atm-vc)# bridge-domain 56 dot1q 46Router(config-if-atm-vc)# exitVerifying the Configuration
Use the following show commands to verify the configuration:
In this example, the vlan ID and dot1q ID values are displayed:
Router# show atm vlan!Options Legend: DQ - dot1q; DT - dot1q-tunnel; MD - multi-dot1q;AC - access; SP - split-horizon; BR - broadcast;DEF - defaultInterface VCD VPI Network Customer PVC Options/VCI Vlan ID Dot1Q-ID StatusATM3/0/0 1 1/21 52 42 UP MDATM3/0/0 1 1/21 53 43 UP MDATM3/0/0 1 1/21 54 44 UP MDATM3/0/0 1 1/21 55 45 UP MDATM3/0/0 1 1/21 56 46 UP MDCBR, SusRate: 2300AAL5-LLC/SNAP, etype:0x0, Flags: 0x2000820, VCmode: 0x0OAM frequency: 0 second(s), OAM retry frequency: 1 second(s)OAM up retry count: 3, OAM down retry count: 5OAM Loopback status: OAM DisabledOAM VC status: Not ManagedILMI VC status: Not ManagedInARP frequency: 15 minutes(s)Transmit priority 1InPkts: 0, OutPkts: 745, InBytes: 0, OutBytes: 67795InPRoc: 0, OutPRoc: 0, Broadcasts: 0InFast: 0, OutFast: 0, InAS: 0, OutAS:745InPktDrops: 0, OutPktDrops: 0InByteDrops: 0, OutByteDrops: 0CRD Errors: 0, SarTimeOuts: 0, OverSizedSDUs: 0, LengthViolation: 0, CPIErrors: 0Out CLP=1 Pkts: 0OAM cells received: 0F5 InEndloop: 0, F5 OUtSegloop:0, F5 OutRDI: 0F4 InEndloop: 0, F4 OUtSegloop:0, F4 OutRDI: 0OAM cell drops: 0Status: UPVLAN Dot1Q LTL InPdts InBytes InDrops OutPkts OutBytes OutDrops================================================================================52 42 0x4 500 500 0 745 67795 053 43 0x4 500 500 0 745 67795 054 44 0x4 500 500 0 745 67795 055 45 0x4 500 500 0 745 67795 056 46 0x4 500 500 0 745 67795 0Configuring Half-Bridging
Note
When you enable half-bridging, Layer 2 ATM traffic received on an ingress port is bridged to destination ports that are on the same subnet, and routed based on IP header information to destination ports that are not in the same subnet. When half-bridging is enabled, Layer 3 forwarding of the Layer 2 ATM traffic does not require the configuration of a switched virtual interface (SVI) to route between the subnets.
The following configuration guidelines apply to half-bridging:
•
•
•
To configure half-bridging on the FlexWAN or Enhanced FlexWAN module, follow these steps:
This example configures half-bridging on a subinterface:
Router(config)# interface atm 3/1/0.2 multipointRouter(config-subif)# ip address 35.0.0.1 255.0.0.0Router(config-subif)# ip mtu 1500Router(config-subif)# pvc 5/100Router(config-subif-atm-vc)# encapsulation aal5snap bridgeConfiguring Distributed Network-Based Application Recognition
The Distributed Network-based Application Recognition (dNBAR) feature, which introduced NBAR on the Cisco 7500 with a Versatile Interface Processor (VIP) and the Catalyst 6000 family switch with a FlexWAN module, is identical in implementation to NBAR. The dNBAR feature was introduced with the Cisco IOS 12.1(6)E Release.
The NBAR feature is used for classifying traffic by protocol. Some examples of class-based QoS features that can be used on traffic after the traffic is classified by NBAR include:
•
•
•
•
•
Configure dNBAR as described at the following URL:
Configuring IP Multicast
The Enhanced FlexWAN module performs IP multicast with hardware replication.
For other line cards, IP multicast is handled by the Multilayer Switch Feature Card (MSFC) and the Policy Feature Card (PFC), both of which are integrated components on the supervisor engine or route switch processor. For additional information on IP multicast, see the Cisco 7600 Series Cisco IOS Software Configuration Guide, 12.2SR, at the following URL: http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/swcg.html
Configuring IGMP Snooping
IGMP snooping constrains the flooding of multicast traffic by dynamically configuring Layer 2 interfaces so that multicast traffic is forwarded to only those interfaces associated with IP multicast devices. As the name implies, IGMP snooping requires the LAN router to snoop on the IGMP transmissions between the host and the router and to keep track of multicast groups and member ports. When the router receives an IGMP report from a host for a particular multicast group, the router adds the host port number to the forwarding table entry; when it receives an IGMP Leave Group message from a host, it removes the host port from the table entry. It also periodically deletes entries if it does not receive IGMP membership reports from the multicast clients.
The multicast router sends out periodic general queries to all VLANs. All hosts interested in this multicast traffic send join requests and are added to the forwarding table entry. The router creates one entry per VLAN in the IGMP snooping IP multicast forwarding table for each group from which it receives an IGMP join request.
For more information and configuration instructions, see the Cisco 7600 Series Router IOS Software Configuration Guide, Release 12.2SR.
Configuring ACFC and PFC Support on Multilink Interfaces
About ACFC and PFC
Using the Address and Control Field Compression (ACFC) and PPP Protocol Field Compression (PFC) Support on Multilink Interfaces feature, you can control the negotiation and application of the Link Control Protocol (LCP) configuration options for ACFC and PFC.
If ACFC is negotiated during Point-to-Point Protocol (PPP) negotiation, Cisco routers may omit the High-Level Data Link Control (HDLC) header on links using HDLC encapsulation. IF PFC is negotiated during PPP negotiation, Cisco routers may compress the PPP protocol field from two bytes to one byte.
The PPP commands described in this section provide options to control PPP negotiation, allowing the HDLC framing and the protocol field to remain uncompressed. These commands allow the system administrator to control when PPP negotiates the ACFC and PFC options during initial LCP negotiations and how the results of the PPP negotiation are applied.
Note
Restrictions and Usage Guidelines
ACFC and PFC should be configured with the link shut down.
Note
Using ACFC and PFC can result in gains in effective bandwidth because they reduce the amount of framing overhead for each packet. However, using ACFC or PFC changes the alignment of the network data in the frame, which in turn can impair the switching efficiency of the packets both at the local and remote ends of the connection. For these reasons, it is generally recommended that ACFC and PFC not be enabled without carefully considering the potential results.
ACFC and PFC options are supported only when the serial interfaces are multilink member interfaces.
ACFC and PFC configured on MLP interfaces do not have any effect during PPP negotiation or during packet transmission.
Supported Platforms
Enhanced FlexWAN/PA
This feature is supported on Enhanced FlexWAN on the following Port Adapters:
•
•
•
Configuring ACFC and PFC Support
The following sections list the configuration tasks for ACFC and PFC handling.
Configuring ACFC Support
To configure ACFC support, perform the following tasks in interface configuration mode:
ACFC Configuration Example
The following example configures the interface to accept ACFC requests from a remote peer and perform ACFC on frames sent to the peer, and include the ACFC option in its outbound configuration in its outbound configuration requests:
Router> enableRouter# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# interface serial 4/1/1/1:0Router(config-if)# shutdownRouter(config-if)# ppp acfc remote applyRouter(config-if)# ppp acfc local requestRouter(config-if)# no shutdownConfiguring PFC Support
To configure PFC support, perform the following tasks in interface configuration mode:
:
PFC Configuration Example
The following example configures the interface to explicitly ignore the PFC option received from a remote peer, and exclude the PFC option from its outbound configuration requests and reject any request from a remote peer to add the PFC option:
Router> enableRouter# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# interface serial 4/1/1/1:0Router(config-if)# shutdownRouter(config-if)# ppp pfc remote rejectRouter(config-if)# ppp pfc local forbidRouter(config-if)# no shutdownConfiguring Distributed Multilink Point-to-Point Protocol
This section describes the implementation of the Distributed Multilink Point-to-Point Protocol (dMLPPP) feature on FlexWAN or Enhanced FlexWAN modules in a Cisco 7600 series router. The dMLPPP feature allows you to combine several T1/E1 lines into a single multilink bundle (an MLPPP link) that has the combined bandwidth of all of the T1/E1 lines in the bundle. This bundling allows you to increase link bandwidth without having to purchase a T3 line.
Non-distributed MLPPP can only perform limited links, with CPU utilization quickly reaching 90% with only a few T1/E1 lines running MLPPP. With distributed MLPPP, you can increase the router's total capacity. Distributed MLPPP supports bundling of fractional T1/E1 starting from DS0 (64 kbps) onwards.
Note
Restrictions and Usage Guidelines
The following restrictions apply to the Distributed Multilink PPP feature:
Note
•
•
•
•
•
•
•
•
•
See Table 6-1 for a summary of feature compatibility on multilink interfaces.
Port Adapters Supported
Table 3-1 shows the FlexWAN and Enhanced FlexWAN port adapters that support Distributed MLPPP.
Configuration Tasks
See the following sections for configuration tasks for the dMLPPP feature.
•
•
•
•
•
Enabling Distributed CEF Switching
To enable distributed MLPPP, you must first enable distributed CEF (dCEF) switching. To enable dCEF, use the ip cef distributed command in global configuration mode:
The following example shows how to turn on dCEF in a Cisco 7600 series router:
ip cef distributed
Creating a Multilink Bundle
To create a multilink bundle, use the following commands beginning in global configuration mode:
The following is an example of creating a multilink bundle:
interface multilink1ip address 10.0.0.0 10.255.255.255ppp chap hostname group 1ppp multilinkmultilink-group 1Assigning an Interface to a Multilink Bundle
To assign an interface to a multilink bundle, get into interface configuration mode for the interface you want to add to the multilink bundle and use the following commands:
The following is an example of assigning an interface to a multilink bundle:
interface serial 1/0/0/:2no ip addressencapsulation pppip route-cache distributedno keepaliveppp chap hostname group 1ppp multilinkmultilink-group 1Disabling PPP Multilink Fragmentation
By default, PPP multilink fragmentation is enabled. To disable PPP multilink fragmentation, use the following command in interface configuration mode:
Router(config-if)# no ppp multilink fragmentation
Disable PPP multilink fragmentation.
Enabling fragmentation reduces the delay latency among bundle links, but adds some load to the CPU. Disabling fragmentation may result in better throughput.
If your data traffic is consistently of a similar size, we recommend disabling fragmentation. In this case, the benefits of fragmentation may be outweighed by the added load on the CPU.
Verifying the Configuration
Use the show ppp multilink command to display information about the newly created multilink bundle:
Router# show ppp multilinkMultilink1, bundle name is group1Bundle is Distributed0 lost fragments, 0 reordered, 0 unassigned, sequence 0x0/0x0 rcvd/sent0 discarded, 0 lost received, 1/255 loadMember links:4 active, 0 inactive (max not set, min not set)Serial1/0/0:1Serial1/0/0/:2Serial1/0/0/:3Serial1/0/0/:4Configuring Multilink Frame Relay
The Distributed Multilink Frame Relay feature introduces functionality based on the Frame Relay Forum Multilink Frame Relay UNI/NNI Implementation Agreement (FRF.16) to FlexWAN- and Enhanced FlexWAN-enabled Cisco 7600 series routers. The Distributed Multilink Frame Relay feature provides a cost-effective way to increase bandwidth for particular applications by enabling multiple serial links to be aggregated into a single bundle of bandwidth. Multilink Frame Relay is supported on User-to-Network Interfaces (UNI) and Network-to-Network Interfaces (NNI) in Frame Relay networks.
Multilink Frame Relay Bundles and Bundle Links
The Multilink Frame Relay feature enables you to create a virtual interface called a bundle or bundle interface. The bundle interface emulates a physical interface for the transport of frames. The Frame Relay data link runs on the bundle interface, and Frame Relay virtual circuits are built upon it.
The bundle is made up of multiple serial links, called bundle links. Each bundle link in a bundle corresponds to a physical interface. Bundle links are invisible to the Frame Relay data-link layer, so Frame Relay functionality cannot be configured on these interfaces. Regular Frame Relay functionality that you want to apply to these links must be configured on the bundle interface. Bundle links are visible to peer devices. The local router and peer devices exchange link integrity protocol control messages to determine which bundle links are operational and to synchronize which bundle links should be associated with which bundles.
Link Integrity Protocol Control Messages
For link management, each end of a bundle link follows the MFR Link Integrity Protocol and exchanges link control messages with its peer (at the other end of the bundle link). To bring up a bundle link, both ends of the link must complete an exchange of ADD_LINK and ADD_LINK_ACK messages. To maintain the link, both ends periodically exchange HELLO and HELLO_ACK messages. This exchange of hello messages and acknowledgments serves as a keepalive mechanism for the link. If a router is sending hello messages but not receiving acknowledgments, it resends the hello message up to a configured maximum number of retry times. If the peer device still does not respond, the bundle link is no longer considered operational—its line protocol status is down.
The bundle link interface's line protocol status is considered up (operational) when the peer device acknowledges that it will use the same link for the bundle. The line protocol remains up when the peer device acknowledges the hello messages from the local router.
The bundle interface's line status comes up when at least one bundle link has its line protocol status up. The bundle interface's line status goes down when the last bundle link is no longer in the up state. This behavior complies with the class A bandwidth requirement defined in FRF.16.
The bundle interface's line protocol status is considered up when the Frame Relay data-link layer at the local router and peer device synchronize using the Local Management Interface (LMI), when LMI is enabled. The bundle interface's line protocol remains up as long as the LMI keepalives are successful.
Load Balancing
Distributed Multilink Frame Relay provides load balancing across the bundle links within a bundle. If a bundle link chosen for transmission is busy transmitting a long packet, the load balancing mechanism can try another link, thus solving the problems seen when delay-sensitive packets have to wait.
Restrictions
The Distributed Multilink Frame Relay feature has the following restrictions:
•
•
•
•
•
•
•
See Table 6-1 for a summary of feature compatibility on distributed multilink Frame Relay interfaces.
Prerequisites
•
•
Configuration Tasks
See the following sections for configuration tasks for the Distributed Multilink Frame Relay feature. Each task in the list is identified as either optional or required.
•
•
•
Configuring a Multilink Frame Relay Bundle Interface
To configure the bundle interface for Distributed Multilink Frame Relay, use the following commands beginning in global configuration mode:
Configuring a Multilink Frame Relay Bundle Link
To configure a bundle link interface for Multilink Frame Relay, use the following commands beginning in global configuration mode:
Verifying Multilink Frame Relay
To verify Multilink Frame Relay configuration, use the show frame-relay multilink command.
The following example shows output for the show frame-relay multilink command. Because a particular bundle or bundle link is not specified, information for all bundles and bundle links is displayed.
Router# show frame-relay multilinkBundle: MFR0, state up, class A, no fragmentationID: Bundle-DallasSerial5/1/0, state up/up, ID: BL-Dallas-1Serial5/3/0, state up/add-sent, ID: BL-Dallas-3Bundle: MFR1, state down, class B, fragmentationID: Bundle-NewYork#1Serial3/0/0, state up/up, ID: BL-NewYork-1Serial3/2/0, state admin-down/idle, ID: BL-NewYork-2The following example shows output for the show frame-relay multilink command with the serial number option. It displays information about the specified bundle link.
Router# show frame-relay multilink serial3/2Bundle links :Serial3/2, HW state :Administratively down, Protocol state :Down_idle, LID :Serial3/2Bundle interface = MFR0, BID = MFR0The following examples show output for the show frame-relay multilink command with the serial number and detail options. Detailed information about the specified bundle links is displayed. The first example shows a bundle link in the "idle" state. The second example shows a bundle link in the "up" state.
Router# show frame-relay multilink serial3 detailBundle links:Serial3, HW state = up, link state = Idle, LID = Serial3Bundle interface = MFR0, BID = MFR0Cause code = none, Ack timer = 4, Hello timer = 10,Max retry count = 2, Current count = 0,Peer LID = Serial5/3, RTT = 0 msStatistics:Add_link sent = 0, Add_link rcv'd = 10,Add_link ack sent = 0, Add_link ack rcv'd = 0,Add_link rej sent = 10, Add_link rej rcv'd = 0,Remove_link sent = 0, Remove_link rcv'd = 0,Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,Hello sent = 0, Hello rcv'd = 0,Hello_ack sent = 0, Hello_ack rcv'd = 0,outgoing pak dropped = 0, incoming pak dropped = 0Router# show frame-relay multilink serial3 detailBundle links:Serial3, HW state = up, link state = Up, LID = Serial3Bundle interface = MFR0, BID = MFR0Cause code = none, Ack timer = 4, Hello timer = 10,Max retry count = 2, Current count = 0,Peer LID = Serial5/3, RTT = 4 msStatistics:Add_link sent = 1, Add_link rcv'd = 20,Add_link ack sent = 1, Add_link ack rcv'd = 1,Add_link rej sent = 19, Add_link rej rcv'd = 0,Remove_link sent = 0, Remove_link rcv'd = 0,Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,Hello sent = 0, Hello rcv'd = 1,Hello_ack sent = 1, Hello_ack rcv'd = 0,outgoing pak dropped = 0, incoming pak dropped = 0Monitoring and Maintaining Distributed Multilink Frame Relay
To monitor and maintain Distributed Multilink Frame Relay, use one or more of the following commands in privileged EXEC mode:
The following example shows the configuration of bundle "MFR1." Serial interfaces 5/0/0 and 6/0/0 are configured as bundle links.
interface MFR1frame-relay multilink bid first-bundleframe-relay traffic-shapingframe-relay class oceaninterface MFR1.1 point-to-pointip address 1.1.1.1 255.255.255.0frame-relay interface-dlci 100interface Serial5/0/0encapsulation frame-relay MFR1frame-relay multilink lid first-linkframe-relay multilink hello 9frame-relay multilink retry 3interface Serial6/0/0encapsulation frame-relay MFR1frame-relay multilink ack 4
Configuring Distributed Link Fragmentation and Interleaving for Frame Relay and ATM Interfaces
The Distributed Link Fragmentation and Interleaving over Leased Lines feature extends distributed link fragmentation and interleaving functionality to leased lines.
Note
The dLFI feature supports the transport of real-time traffic, such as voice, and non-real-time traffic, such as data, on lower-speed Frame Relay and ATM virtual circuits (VCs) and on leased lines without causing excessive delay to the real-time traffic.
This feature is implemented using Multilink PPP (MLPPP) over Frame Relay, ATM, and leased lines. The feature enables delay-sensitive real-time packets and non-real-time packets to share the same link by fragmenting the large data packets into a sequence of smaller data packets (fragments). The fragments are then interleaved with the real-time packets. On the receiving side of the link, the fragments are reassembled and the packet reconstructed.
The dLFI feature is often useful in networks that send real-time traffic using Distributed Low Latency Queueing, such as voice, but have bandwidth problems that delay this real-time traffic due to the transport of large, less time-sensitive data packets. The dLFI feature can be used in these networks to disassemble the large data packets into multiple segments. The real-time traffic packets then can be sent between these segments of the data packets. In this scenario, the real-time traffic does not experience a lengthy delay waiting for the low-priority data packets to traverse the network. The data packets are reassembled at the receiving side of the link, so the data is delivered intact.
The ability to configure Quality of Service (QoS) using the Modular QoS CLI while also using distributed MLP (dMLP) is also introduced as part of the dLFI feature. Previoulsy, you could not configure QoS using the Modular QoS CLI while using dMLP.
Note
- Without an MLP header.
- If the policy is applied on the ingress side of the MLP bundle.
This difference narrows down as the size of the packet increases say, from 50 to 480 bytes. This behavior is expected owing to line card architecture.Figure 3-1 illustrates how dLFI fragments a larger data packet to allow time-sensitive traffic, in this case voice traffic, to be delivered in a more timely manner.
Figure 3-1 Distributed Link Fragmentation and Interleaving Example
Restrictions
The following restrictions apply to the Distributed Link Fragmentation and Interleaving feature:
•
–
–
–
–
Note
•
•
Note
QoS traffic policies will function properly in MLP bundles with more than one link, however.
•
See Table 6-1 for a summary of feature compatibility with dLFI.
Related Features and Technologies
•
•
•
•
–
–
–
–
–
–
Prerequisites
The following prerequisites apply to dLFI support on the FlexWAN module:
•
The priority policy map class command is used to configure dLLQ in a QoS traffic policy, and the service-policy interface command is used to attach the QoS traffic policy to an interface or a PVC.
•
•
–
–
–
–
–
–
–
–
–
HSSI
–
–
•
–
–
–
Note
Configuration Tasks
See the following sections for configuration tasks for the dLFI feature. Each task in the list is identified as optional or required.
•
•
•
•
Configuring LFI Using MLP over Frame Relay
To configure LFI using MLP over Frame Relay, perform the tasks in the following sections:
•
•
•
Configuring Distributed Low Latency Queueing and Other QoS Features in a Traffic Policy
The dLLQ feature must be enabled for the dLFI feature to interleave packet fragments. You configure the dLLQ feature in a QoS traffic policy, which is attached to the multilink group. You can also configure other QoS features in the traffic policy.
To configure a traffic policy that uses dLLQ and other QoS features, enter the following commands:
Configuring LFI Using MLP on a Virtual Template Interface
To configure LFI using MLP on a virtual template interface, use the following interface configuration commands:
Step 1
Router(config)# interface virtual-template number
Creates a virtual template and enters interface configuration mode.
Step 2
Router(config-if)# bandwidth kilobits
Sets the bandwidth value for an interface. The bandwidth value for the interface should match the traffic speed of the PVC; for instance, if the VBR peak cell rate is 128 kpbs, the kilobits option in the bandwidth command should be entered as 128. Similarly, if the PVC is being shaped to 64 kpbs, the kilobits option should be entered as 64.
Step 3
Router(config-if)# ip address ip-address mask
Sets a primary IP address for an interface.
Step 4
Router(config-if)# service-policy output policy-name
(Required for traffic leaving the virtual template interface) Attaches a previously configured QoS traffic policy, which contains QoS classification and configuration parameters, that evaluates and applies QoS features for traffic leaving the interface with the virtual template.
The priority command must be configured in this traffic policy for dLFI to operate properly. In this example, the policy-name option should match the policy-name option given in Step 4 of the Configuring Distributed Low Latency Queueing and Other QoS Features in a Traffic Policy procedure.
Note
Step 5
Router(config-if)# service-policy input policy-name
(Required for traffic entering the virtual template interface) Attaches a previously configured QoS traffic policy, which contains QoS classification and configuration parameters, that evaluates and applies QoS features, including dLLQ, for traffic entering the interface with the virtual template.
The priority command must be configured in this traffic policy for dLFI to operate properly. In this example, the policy-name option should match the policy-name option given in Step 4 of the Configuring Distributed Low Latency Queueing and Other QoS Features in a Traffic Policy procedure.
Note
Step 6
Router(config-if)# ppp multilink
Enables MLP on the interface.
Step 7
Router(config-if)# ppp multilink fragment-delay milliseconds
Configures the maximum delay allowed for transmission of a packet fragment on an MLP bundle.
Step 8
Router(config-if)# ppp multilink interleave
Enables interleaving of packets among the fragments of larger packets on an MLP bundle.
Fragment size at the MLP bundle can be configured using the following formula:
fragment size = bandwidth x fragment-delay / 8
Associating the Virtual Template Interface with a Frame Relay PVC
To associate the virtual template interface with a Frame Relay PVC, use the following commands beginning in global configuration mode:
Step 1
Router(config)# interface type number
Configures an interface type and enters interface configuration mode.
Step 2
Router(config-if)# frame-relay interface-dlci dlci [ppp virtual-template-name]
Associates a virtual template interface with a Frame Relay DLCI.1
1 DLCI = data-link connection identifier
Configuring LFI Using MLP over ATM
LFI using MLP can be configured over ATM using a virtual template interface. To configure LFI using MLP over ATM using a virtual template interface, perform the tasks in the following sections:
•
•
•
Configuring Distributed Low Latency Queueing and Other QoS Features in a Traffic Policy
The dLLQ feature must be enabled in order for the dLFI feature to interleave packet fragments. The dLLQ feature is configured in a QoS traffic policy, which is attached to the multilink group. Other QoS features can also be configured in the traffic policy.
To configure a traffic policy that uses dLLQ and other QoS features, enter the following commands:
:
Configuring LFI Using MLP in a Virtual Template Interface
To configure dLFI using MLP on a virtual template interface, use the following interface configuration commands:
Step 1
Router(config)# interface virtual-template number
Creates a virtual template and enters interface configuration mode.
Step 2
Router(config-if)# bandwidth kilobits
Sets the bandwidth value for an interface.
Step 3
Router(config-if)# ip address ip-address mask
Sets a primary IP address for an interface.
Step 4
Router(config-if)# service-policy output policy-name
(Required for traffic leaving the virtual template interface) Attaches a previously configured QoS traffic policy, which contains QoS classification and configuration parameters, that evaluates and applies QoS features, including dLLQ, for traffic leaving the interface with the virtual template.
The priority command must be configured in this traffic policy for dLFI to operate properly. In this example, the policy-name option should match the policy-name option given in Step 4 of the Configuring Distributed Low Latency Queueing and Other QoS Features in a Traffic Policy procedure.
Note
Step 5
Router(config-if)# service-policy input policy-name
(Required for traffic entering the virtual template interface) Attaches a previously configured QoS traffic policy, which contains QoS classification and configuration parameters, that evaluates and applies QoS features, including dLLQ, for traffic entering the interface with the virtual template.
The priority command must be configured in this traffic policy for dLFI to operate properly. In this example, the policy-name option should match the policy-name option given in Step 4 of the Configuring Distributed Low Latency Queueing and Other QoS Features in a Traffic Policy procedure.
Note
Step 6
Router(config-if)# ppp multilink
Enables MLP on the interface.
Step 7
Router(config-if)# ppp multilink fragment-delay milliseconds
Configures the maximum delay allowed for transmission of a packet fragment on an MLP bundle.
Step 8
Router(config-if)# ppp multilink interleave
Enables interleaving of packets among the fragments of larger packets on an MLP bundle.
Fragment size at the MLP bundle can be configured using the following formula:
fragment size = bandwidth x fragment-delay / 8
The ideal fragment size for MLP over ATM should allow the fragments to fit into an exact multiple of ATM cells. The fragment size for MLP over ATM can be calculated using the following formula:
fragment size = 48 x number of cells - 10
Associating the Virtual Template Interface with an ATM PVC
To associate the virtual template interface with an ATM PVC, use the following commands beginning in global configuration mode:
Step 1
Router(config)# interface atm slot/0
or
Router(config)# interface atm slot/subslot/port
Specifies the ATM interface type and enters interface configuration mode.1
Step 2
Router(config-if)# pvc [name] vpi/vci
Creates an ATM PVC.
Step 3
Router(config-if-atm-vc)# abr output-pcr output-mcr
Selects ABR2 QoS and configures the output peak cell rate and output minimum guaranteed cell rate for an ATM PVC.
Step 4
Router(config-if-atm-vc)# protocol ppp virtual-template number
Specifies that PPP is established over the ATM PVC using the configuration from the specified virtual template.
1 To determine the correct form of the interface atm command, consult your ATM network module, port adapter, or router documentation.
2 ABR = available bit rate
Configuring LFI Using MLP over a Leased Line
LFI over a leased line can be configured using MLP. To configure LFI over a leased line, perform the tasks in the following sections:
•
•
•
•
Configuring Distributed Low Latency Queueing and Other QoS Features in a Traffic Policy
The dLLQ feature must be enabled in order for the dLFI feature to interleave packet fragments. The dLLQ feature is configured in a QoS traffic policy which is attached to the multilink group. Other QoS features can also be configured in the traffic policy.
A traffic policy using dLLQ and other QoS features can be configured by entering the following commands:
Note
1. Use bandwidth percent instead of bandwidth kpbs if possible. If the bandwidth kpbs option is specified as member links join and leave the bundle, the bandwidth setting will not adjust to the new aggregate bandwidth and the QoS traffic policy will either consume more bandwidth than desired or not have enough available bandwidth. Because the bandwidth percent option adjusts accordingly when new members links are added or removed, the amount of available bandwidth is properly adjusted when new member links are added or removed.
2. If bandwidth kpbs must be used, specify a bandwidth statement for the multilink group to reflect the expected available bandwidth for the multilink group. This bandwidth should be identical to the amount of bandwidth specified in the channel configuration when the channel-group command is entered (See Step 2 in the "Configuring the Channel Group" section of this document). For example, if two channels are defined using the DS0 rate (64 kpbs), the kilobits variable should be entered as 128.
Configuring the Channel Group
A channel group is used to configure the controllers. To configure the controller, enter the following commands:
Creating a Multilink Group
To create a multilink group, use the following commands beginning in interface configuration mode:
Step 1
Router(config)# interface multilink group-number
Creates and names a multilink bundle. The name of the multilink bundle is the group-number.
Step 2
Router(config-if)# ip address ip-address mask
Assigns an IP address for the multilink group.
Step 3
Router(config-if)# bandwidth kilobits
(Optional, unless a QoS traffic policy using the bandwidth kpbs command will be attached to the multilink group) Sets the bandwidth value for an interface.
The bandwidth should match the parameters defined in channel configuration. For instance, if two channels are defined using the DS0 rate (64 kpbs), the kilobits variable should be entered as 128.
Step 4
Router(config-if)# ppp multilink
Enables MLP for the multilink group.
Step 5
Router(config-if)# ppp multilink fragment-delay milliseconds
Configures the maximum delay allowed for transmission of a packet fragment on an MLP bundle.
Step 6
Router(config-if)# ppp multilink interleave
Enables interleaving of packets among the fragments of larger packets on an MLP bundle.
Step 7
Router(config-if)# service-policy output policy-name
(Required for traffic leaving the multilink group) Attaches a previously configured QoS traffic policy, which contains QoS classification and configuration parameters, that evaluates and applies QoS features, including dLLQ, for traffic leaving the interface bundle.
The priority command must be configured in this traffic policy for dLFI to operate properly. In this example, the policy-name option should match the policy-name option given in Step 4 of the Configuring Distributed Low Latency Queueing and Other QoS Features in a Traffic Policy procedure.
Note
Step 8
Router(config-if)# service-policy input policy-name
(Required for traffic entering the multilink group) Attaches a previously configured QoS traffic policy, which contains QoS classification and configuration parameters, that evaluates and applies QoS features, including dLLQ, for traffic entering the interface bundle.
The priority command must be configured in this traffic policy for dLFI to operate properly. In this example, the policy-name option should match the policy-name option given in Step 4 of the Configuring Distributed Low Latency Queueing and Other QoS Features in a Traffic Policy procedure.
Note
Assigning an Interface to a Multilink Group
To configure an interface and attach the interface to a multilink group, use the following commands beginning in interface configuration mode:
Step 1
Router(config)# interface serial interface-number
Specifies the serial interface to configure. Only serial interfaces can be bundled using multilink groups.
Step 2
Router(config-if)# no ip address
Removes any specified IP address.
Step 3
Router(config-if)# keepalive [seconds]
Sets the keepalive interval for the interface. The keepalive interval, which is the frequency at which the Cisco IOS software sends messages to itself or to the other end, is used to ensure a network interface is up. The seconds variable determines how often these messages are sent; for instance, if keepalive 5 is entered, a keepalive message is sent every 5 seconds.
Step 4
Router(config-if)# ppp chap hostname hostname
Specifies the hostname for the interface when Challenge Handshake Authentication Protocol (CHAP) is used for authentication. The CHAP hostname must be configured in order to avoid potential errors when more than one multilink group exists between the same two routers.
A different hostname should be specified for each multilink group on a router.
Step 5
Router(config-if)# ppp multilink
Enables multilink PPP for the interface.
Step 6
Router(config-if)# multilink-group group-number
Assigns the interface to a multilink group. To assign the interface to a previously configured multilink group, the group-number variable in this step must match the group-number variable specified in the multilink group (in the "Creating a Multilink Group" section of this document, the group-number for the multilink group is specified in Step 1).
Verifying LFI for Frame Relay, ATM, or Leased Lines
To display information about LFI for Frame Relay, ATM, or leased lines using MLP, use the following privileged EXEC commands:
Monitoring LFI for Frame Relay, ATM, or Leased Lines
To monitor LFI for Frame Relay, ATM, or leased lines using MLP, use the following privileged EXEC commands:
Note
LFI Configuration Examples
This section provides the following configuration examples:
•
•
•
LFI over Frame Relay Configuration Example
The following example shows the configuration of LFI using MLP over Frame Relay using a virtual template interface:
class-map voipmatch ip precedence 5class-map businessmatch ip precedence 3policy-map llq-policyclass voippriority 32class businessbandwidth 32policy-map shape-llq-policyclass class-defaultshape average 80000 320 320service-policy llq-policypolicy-map input-policyclass voippolice 32000 1500 1500 conform-action transmit exceed-action dropcontroller T1 5/1/0framing esflinecode b8zschannel-group 0 timeslots 1-2interface Serial5/1/0:0no ip addressencapsulation frame-relayinterface Serial5/1/0:0.1 point-to-pointframe-relay interface-dlci 20 ppp Virtual-Template2interface Virtual-Template2bandwidth 78ip address 98.0.0.2 255.0.0.0no keepaliveservice-policy output llq-policyservice-policy input input-policyppp multilinkppp multilink fragment-delay 8ppp multilink interleaveLFI over ATM Configuration Example
The following example shows the configuration of LFI using MLP on an ATM interface. This configuration uses a virtual template interface.
class-map voipmatch ip precedence 5class-map businessmatch ip precedence 3policy-map llq-policyclass voippriority 32class businessbandwidth 32policy-map input-policyclass voippolice 32000 1500 1500 conform-action transmit exceed-action dropinterface ATM4/0/0no ip addressno atm ilmi-keepaliveinterface ATM4/0/0.1 point-to-pointpvc 0/34abr 100 80protocol ppp Virtual-Template4interface Virtual-Template4bandwidth 78ip address 88.0.0.2 255.0.0.0service-policy output llq-policyservice-policy input input-policyppp multilinkppp multilink fragment-delay 8ppp multilink interleaveLFI over Leased Line Configuration Example
The following example shows the configuration of LFI over a leased line. LFI must use an MLP bundle to be used over a leased line.
class-map voipmatch ip precedence 5class-map businessmatch ip precedence 3policy-map llq-policyclass voippriority 32class businessbandwidth 32policy-map input-policyclass voippolice 32000 1500 1500 conform-action transmit exceed-action dropcontroller T1 5/1/0channel group 0 timeslots 1-2interface multilink 2ip address 172.16.0.0 255.0.0.0keepalive 5bandwidth 128ppp multilinkppp multilink fragment-delay 8ppp multilink interleaveservice-policy output llq-policyservice-policy input input-policymultilink-group 2interface serial5/0/0:0no ip addressencapsulation pppkeepalive 5ppp chap hostname G2ppp multilinkmultilink-group 2Monitoring LFI Example
In the following example, the show ppp multilink command is used to monitor dLFI traffic. Note that this command output provides the numbers of fragmented, unfragmented, and reassembled packets entering and leaving the bundle.
Router#show ppp multilinkMultilink11, bundle name is G11Bundle is Distributed0 lost fragments, 0 reordered, 0 unassigned0 discarded, 0 lost received, 1/255 load0x0 received sequence, 0x14 sent sequenceMember links:2 active, 0 inactive (max not set, min not set)Serial4/1/1:2, no frags rcvd 64 weight, 2 max fragmentsSerial4/1/1:3, no frags rcvd 64 weight, 2 max fragmentsdLFI statistics:DLFI Packets Pkts In Chars In Pkts Out Chars OutFragmented 20 1372 20 1372UnFragmented 0 0 0 0Reassembled 2 1228 2 1228Reassembly Drops 0Fragmentation Drops 0Out of Seq Frags 0Configuring Compressed Real-Time Protocol (CRTP)
Compressed Real-Time Protocol (CRTP), RFC1889, provides bandwidth efficiencies over low-speed links by compressing the UDP/RTP/IP header when transporting voice. With CRTP, the header for voice-over-IP traffic can be reduced from 40 bytes to approximately 2 to 5 bytes, offering substantial bandwidth efficiencies for low-speed links. Table 3-2 lists the port adapters that support CRTP.
For information on configuring CRTP, see Configuring Distributed Compressed Real-Time Protocol at:
http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfdcrtp.html
Configuring Distributed CRTP
If the Distributed CRTP (dCRTP) feature is enabled, the header compression of the combined IP/UDP/RTP header occurs by default in the distributed fast-switched path or the distributed CEF-switched (dCEF-switched) path, depending on which switching method is enabled on the interface.
Restrictions and Usage Guidelines
•
•
•
•
Prerequisites
For this feature to work, the following prerequisites must be met:
•
•
–
–
Configuration Tasks
This document assumes that TCP or RTP header compression (or both) is already enabled (see Prerequisites).
If TCP or RTP header compression is enabled, the header compression is performed in the distributed CEF-switched or distributed fast-switched path automatically. No additional configuration tasks are required.
The following task is optional:
•
Changing the Number of Header Compression Connections
By default, for Frame Relay encapsulation, there can be 256 TCP header compression connections and 256 RTP header compression connections (128 calls for each type). The maximum value is fixed and is not configurable.
By default, for PPP or HDLC encapsulation, the software allows 32 TCP header compression connections (16 calls). This default can be increased to a maximum of 256 TCP header compression connections. The software also allows 32 RTP header compression connections (16 calls). This default can be increased to a maximum of 1000 RTP header compression connections on an interface.
To change the number of compression connections supported, use the appropriate command in interface configuration mode:
The following example shows the output of the show ip rtp header command when a Cisco 7600 with a FlexWAN or Enhanced FlexWAN module has the dCRTP feature enabled. When the dCRTP feature is disabled, the distributed fast switched line of the output, which is in italics for emphasis, does not appear.
Router# show ip rtp headerRTP/UDP/IP header compression statistics:Interface Serial4/1/1:Distributed fast switched:8 seconds since line card sent last stats updateRcvd: 0 total, 0 compressed, 0 errors0 dropped, 0 buffer copies, 0 buffer failuresSent: 0 total, 0 compressed,0 bytes saved, 0 bytes sentConnect:16 rx slots, 16 tx slots,0 long searches, 0 misses 0 collisionsThe following example shows the output of the show ip tcp header command when a Cisco 7600 router with a FlexWAN or Enhanced FlexWAN module has the dCRTP feature enabled. When the dCRTP feature is disabled, the distributed fast switched line of output (shown in italics below) does not appear.
Router# show ip tcp headerTCP header compression statistics:Interface Serial4/1/1:Distributed fast switched: 8 seconds since line card sent last stats updateRcvd: 0 total, 0 compressed, 0 errors0 dropped, 0 buffer copies, 0 buffer failuresSent: 0 total, 0 compressed,0 bytes saved, 0 bytes sentConnect:16 rx slots, 16 tx slots,0 long searches, 0 misses 0 collisions
Configuring Voice over Frame Relay (VoFR) FRF.11 and FRF.12
FRF.12 is standards-based link fragmentation and interleaving over Frame Relay links. FRF.12 supports real-time voice over Frame Relay links by fragmenting large data packets and interleaving fragmented data packets with voice packets, thereby minimizing end-to-end latency and jitter. On the receiving end, the fragmented packets are reassembled.
FRF.11 Voice over Frame Relay is a Frame Relay standard that defines the encapsulation and transport of voice and data across a Frame Relay link. Voice and data are carried across sub-channels on a Frame Relay link. This feature enables a Cisco 7600 series router or Catalyst 6500 series switch to function as a Frame Relay tandem switch for voice and data.
For more information, see the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2 at http://www.cisco.com/en/US/docs/ios/12_2/voice/configuration/guide/vvfvofr.html
Note
Restrictions and Usage Guidelines
•
•
•
•
•
•
•
•
Prerequisites
Before you can configure Voice over Frame Relay, you must do the following:
•
•
http://www.cisco.com/en/US/docs/ios/12_2/wan/configuration/guide/fwan_c.html
•
–
–
After you have analyzed your dial plan and decided how to integrate it into your existing Frame Relay network, you are ready to configure your network devices to support Voice over Frame Relay.
Configuration Tasks
This section describes the following new and modified configuration procedures for Voice over Frame Relay:
•
•
•
•
•
For all remaining Voice over Frame Relay procedures, see the "Configuring Voice over Frame Relay" chapter in Cisco IOS Multiservice Applications Configuration Guide for Cisco IOS Release 12.1.
Configuring Dial Peer Digit Manipulation
To configure dial peer digit manipulation to forward digits, perform the following steps beginning in global configuration mode:
Configuring Dial Peer Hunting
After you have configured dial peers, you can configure how the router performs dial peer hunting functions. To configure the dial peer hunting behavior on the router, perform the following steps beginning in global configuration mode:
Disabling Dial Peer Hunting on a Specific Dial Peer
If using dial peer hunting, there may be situations when you want to disable dial peer hunting on a specific dial peer. To disable dial peer hunting on a dial peer, use the following commands beginning in global configuration mode:
To reenable dial peer hunting on a dial peer, enter the no huntstop command.
Configuring a Frame Relay Map Class to Support Voice over Frame Relay Fragmentation
To configure a map class to support FRF.11 on a FlexWAN or Enhanced FlexWAN module on a Cisco 7600 router, use the following commands to configure a service policy and apply this service policy in map class configuration mode:
Configuring Voice over Frame Relay Connections
After you have configured the Frame Relay data-link connection identifier (DLCI) settings and you have configured your dial plan, you are ready to configure specific VoFR connections.
There are many different scenarios for VoFR connections. For information on the different connection types, see the next section, "Overview of Voice over Frame Relay Connection Types."
For procedures on how to configure the different connection types, see the following sections:
•
•
•
In addition, special consideration is required for configuring calls for tandem nodes. For more information, see the "Configuring Connections for Tandem Nodes" section.
Note
Overview of Voice over Frame Relay Connection Types
When you configure VoFR connections, you can use many different connection types depending on the hardware platform, whether the call is to be a regular switched (user-dialed or auto-ringdown) call, or whether the call is a permanent call (Cisco-trunk or FRF.11-trunk). You configure these specific connection types by using combinations of several commands.
Table 3-3 lists the different connection types for VoFR connections supported on the FlexWAN or Enhanced FlexWAN module, and the combinations of commands to enter for each call type.
Table 3-3 Supported Voice over Frame Relay Connection Types
Switched call
(user-dialed or auto-ringdown) to other routers supporting VoFRvofr [data cid]
[call-control [cid]]1FRF.11 Annex C
session protocol cisco-switched2
For user-dialed calls: none
For auto-ringdown calls:
connection plar destination-stringSwitched call
(user-dialed or auto-ringdown)
to a Cisco MC3810 running
Cisco IOS Releases before 12.1(2)Tvofr cisco3
Cisco proprietary4
session protocol cisco-switched
For user-dialed calls: none
For auto-ringdown calls:
connection plar destination-stringCisco-trunk
permanent call (private line) to other routers supporting VoFRvofr data cid
call-control cidFRF.11 Annex C
session protocol cisco-switched
connection trunk destination-string [answer mode]
Cisco-trunk
permanent call
(private line)
to a Cisco MC3810 running
Cisco IOS Releases before 12.1(2)Tvofr cisco
Cisco proprietary
session protocol cisco-switched
connection trunk destination-string [answer mode]
FRF.11 trunk call (private line) to other routers supporting VoFR
vofr [data cid] [call-control cid]5
FRF.11 Annex C
session protocol frf11-trunk
connection trunk destination-string [answer mode]
1 The recommended use of this command is vofr data 4 call-control 5.
2 The session protocol cisco-switched option is the default setting. If you do not enter this command, the setting still applies.
3 This command consumes data CID 4 and call-control CID 5.
4 Cisco proprietary fragmentation is based on an early draft of FRF.12 and is compatible with Cisco MC3810 concentrators running software releases before Cisco IOS Release 12.0(3)XG or Release 12.0(4)T.
5 For FRF.11 trunk calls, the call-control option is not required. It is only required if you mix FRF.11 trunk calls with other types of voice calls on the same PVC.
Configuring Switched Calls (User-Dialed or Auto-Ringdown)
This section describes how to configure switched calls (user-dialed or auto-ringdown) on the different router platforms. This section is divided into the following procedures:
•
•
Configuring Switched Calls to Other Voice over Frame Relay Routers
To configure switched calls on routers that support VoFR, use the following commands from interface configuration mode:
This configuration uses standard FRF.11 Annex C fragmentation.
Configuring Switched Calls to a Cisco MC3810 Running Cisco IOS Releases Before 12.1(2)T
You can configure switched calls to Cisco MC3810 concentrators running Cisco IOS releases before 12.1(2)T. However, the configuration is different from standard switched calls because earlier Cisco MC3810 releases used the Cisco proprietary version of FRF.12.
Note
To configure switched calls to a Cisco MC3810 running Cisco IOS releases before 12.1(2)T, use the following commands beginning in interface configuration mode:
This configuration uses Cisco proprietary data fragmentation.
Configuring Cisco-Trunk Permanent (Private Line) Calls
This section describes how to configure Cisco-trunk permanent (private line) calls on the different router platforms. This section is divided into the following procedures:
•
•
•
Configuring Voice over Frame Relay Dial Peers for Cisco-Trunk (Private Line) Calls
If you are sending Cisco-trunk (private line) calls over the Frame Relay network, you must configure the Voice over Frame Relay dial peers to specifically support Cisco-trunk (private line) calls. Cisco-trunk (private line) calls are permanent calls.
One key task when you configure Cisco-trunk (private line) connections is to configure the signal type for the dial peer. The signal-type dial peer command supports the following options:
•
•
•
•
Configure the signal type so that the signal type that is selected in the dial peers on the routers at both ends of the permanent voice call are the same.
To configure a VoFR dial peer to support Cisco-trunk permanent (private line) calls, use the following commands beginning in global configuration mode:
Configuring Cisco-Trunk Permanent Calls
You can configure Cisco-trunk permanent calls on a FlexWAN or Enhanced FlexWAN module on the Cisco 7600 series router.
Note
To configure Cisco-trunk permanent calls, use the following commands from interface configuration mode:
This configuration uses standard FRF.11 Annex C fragmentation.
Note
Configuring Cisco-Trunk Permanent Calls to a Cisco MC3810 Running Cisco IOS Releases Before 12.1(2)T
To configure Cisco-trunk permanent calls to a Cisco MC3810 running Cisco IOS releases before 12.1(2)T, use the following commands from interface configuration mode:
This configuration uses Cisco proprietary data fragmentation.
Note
Configuring FRF.11 Trunk (Private Line) Calls
On a FlexWAN or Enhanced FlexWAN module, you can configure FRF.11 trunk calls to a second router.
You cannot configure FRF.11 trunk calls for tandem VoFR configurations.
Note
To configure FRF.11 trunk (private line) calls, enter the following commands from interface configuration mode:
This configuration uses FRF.11 Annex C data fragmentation.
Note
Configuring Connections for Tandem Nodes
Tandeming is switching incoming VoFR calls on a Frame Relay DLCI to an outgoing VoFR enabled DLCI. Tandeming works for switched calls and Cisco-trunk permanent calls only. You cannot tandem FRF.11 trunk calls over a multi-hop network.
Tandeming is supported on all platforms that support Voice over Frame Relay Using FRF.11 and FRF.12, including FlexWAN or Enhanced FlexWAN modules on Cisco 7600 series routers.
Depending on which router is used as the end node and which router is used as the tandem node, you must use the correct Frame Relay PVC type when configuring your connections. Table 3-4 shows the different combinations of routers that can serve as end nodes and tandem nodes and the Frame Relay PVC type required.
When you configure a tandem node, you must configure two VoFR dial peers, one for each tandem connection.
Verifying Your Voice Connections
Verify that the voice connection for switched calls is working by following these steps:
Step 1
Step 2
Verify that the voice connection for FXO-FXS trunk calls from a telephone to a remote PBX is working by doing the following:
Step 1
Step 2
You can check the validity of your dial peer and voice port configurations by performing the following tasks:
•
•
•
You can check the validity of your VoFR configuration on the DLCI by performing the following task:
•
Troubleshooting Tips
If you are having trouble connecting a call, you can try to resolve the problem by performing the following tasks:
•
•
•
•
•
•
•
•
Configuration Examples
Two Routers Using Frame Relay Fragmentation
This is an example of Frame Relay fragmentation between a Cisco 3600 series router and a FlexWAN or Enhanced FlexWAN module on a Cisco 7600 series router. This configuration uses FRF.12 fragmentation.
This example assumes that a map class called frf12-class was previously configured.
Two Routers Using a VoFR PVC
This example shows an example of Frame Relay fragmentation between a FlexWAN or Enhanced FlexWAN module on a Cisco 7600 series router and a Cisco 3600 series router.
This configuration uses FRF.11 Annex C fragmentation.
Cisco-Trunk (Private Line) Calls Between Two Routers
This is an example of VoFR Cisco-trunk (private line) calls between two routers.
FRF.11 Trunk Calls Between Two Routers
This is an example of FRF.11 trunk calls configured between two routers.
Tandem Configuration with Three Routers for Switched Calls
This is an example of a tandem configuration with a Cisco 3600 router and a FlexWAN or Enhanced FlexWAN module on Cisco 7600 series router as endpoints and a Cisco 3600 as a tandem node.
Tandem Configuration with a Cisco MC3810 Tandem Node for Switched Calls
This is an example of a tandem configuration with a Cisco MC3810 acting as a tandem node.
Tandem Configuration with a Cisco MC3810 Endpoint Node for Cisco-Trunk (Private Line) Calls
This is an example of a tandem configuration with a Cisco MC3810 Digital Voice Interface T1 Card acting as an endpoint node for Cisco-trunk (private line) calls.
Cisco-Trunk Call with Hunt Groups
This is an example of a Cisco-trunk (private line) call that is configured with hunt groups. In this example, the two routers are in master-slave mode with a backup path. Router B is configured as a slave and Router A is configured as the master. The master makes periodic attempts to establish the trunk until the trunk is established.
Two dial peers match the destination string configured in the voice port, but because one dial peer has a higher preference than the other dial peer, the call setup is attempted through that dial peer. If the call setup fails, the master can continue attempting call setups by using the next available dial peer. After all dial peers are exhausted, the master can continue following the list cyclically by starting again from the dial peer with the highest preference.
Configuring Frame Relay Virtual Circuit (VC) Bundling
Frame Relay permanent virtual circuit (PVC) bundle functionality allows you to associate a group of Frame Relay PVCs with a single next-hop address. For information on configuring this feature, see Frame Relay PVC Bundles with QoS Support for IP and MPLS at:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ft_frbnd.html
Note
Note
Configuring Routed Bridged Encapsulation
The FlexWAN and Enhanced FlexWAN modules support Routed Bridged Encapsulation (RBE). Routed Bridged Encapsulation is the process by which a stub-bridged segment is terminated on a point-to-point routed interface. Specifically, the router is routing on an IEEE 802.3 or Ethernet header carried over a point-to-point protocol, such as PPP/BCP, RFC 1483 ATM, or RFC 1490 Frame Relay.
RBE was developed to address the known RFC 1483 bridging issues, including broadcast storms and security (see the "Configuring Half-Bridging" section). Except for the fact that it operates exclusively over ATM, the RBE feature functions identically to half-bridging. Additional scalability, performance, and security can be achieved by using the unique characteristics of xDSL subscribers.
To configure a point-to-point subinterface and PVC for RBE bridging, see the "RBE Configuration Procedure" section.
Tip
RBE Restrictions and Usage Guidelines
Routed Bridged Encapsulation (RBE) has the following restrictions and limitations:
•
•
•
•
•
•
•
•
•
•
•
•
RBE Configuration Limitation Supports Only One Remote MAC Address
On the Cisco 7600 series router with a Sup720 or RSP720, the following ATM port adapters and SPAs with an RBE configuration can send packets to only a single MAC address:
•
•
The remote MAC address restriction occurs because the Cisco 7600 series router keeps only one MAC address attached to an RBE PVC on the FlexWAN, Enhanced FlexWAN, or SIP. The MAC address-to-PVC mapping is refreshed when a packet is received from the host. If multiple hosts are connected to the PVC, the mapping will not be stable and traffic forwarding will be affected.
To resolve this problem, perform the following steps:
1.
2.
Supervisor Engine and Line Card Support for RBE
The following Cisco 7600 Supervisor Engines support RBE:
•
•
•
•
The following Cisco 7600 line cards and SIPs support RBE:
•
•
•
See the Cisco 7600 Series Router Module Release Notes for information about supported line card and port adapter combinations.
ATM Port Adapters Supported for RBE
Routed Bridged Encapsulation is supported on the following ATM port adapters:
•
•
•
•
•
•
•
•
•
•
RBE is also supported on these SPAs (which are only available on the Cisco 7600 SIP-200 and Cisco 7600 SIP-400):
•
•
Note
RBE Configuration Procedure
To configure ATM Routed Bridged Encapsulation, use the following commands:
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(config)# interface atm slot/subslot/port.subinterface point-to-point
Creates a multipoint subinterface on the specified port and enters subinterface configuration mode (slot/subslot/port specifies the location of the FlexWAN/port adapter or SIP/SPA and the physical port to create the subinterface on, and .subinterface specifies an identifier for the subinterface).
Step 3
Router(config-subif)# atm route-bridge ip
Enables ATM RFC 1483 half-bridging (RBE bridging).
Note
Note
Step 4
Router(config-subif)# mpls ip
(Optional) Enables MPLS on the RBE interface. For information on this feature, see the "MPLS Over RBE" section on page 2-9.
Step 5
Router(config-subif)# ip address address mask [secondary]
Assigns the specified IP address (address) and subnet mask (mask) to this subinterface. The optional keyword secondary configures the IP address as a secondary address (see the Cisco IOS Command Reference for details on this keyword).
Note
Note
Step 6
Router(config-subif)# pvc [name] vpi/vci
Configures a new ATM PVC by assigning its VPI/VCI numbers and enters ATM VC configuration mode.
•
•
•
Note
Step 7
Router(config-if-atm-vc)# encapsulation aal5snap
(Optional) Configures the ATM adaptation layer (AAL) and encapsulation type. The only supported encapsulation for an RBE PVC is aal5snap.
Step 8
Router(config-if-atm-vc)# end
Exits ATM VC configuration mode and returns to privileged EXEC mode.
Verifying the Routed Bridged Encapsulation Configuration
To verify the RBE bridging configuration, use any of the following commands. Examples of some of the commands are shown below.
•
•
•
Following is an example of command output for the show arp command:
Router# show arpProtocol Address Age (min) Hardware Addr Type InterfaceInternet 122.0.0.1 6 00d0.04f7.5c00 ARPA ATM2/0/0.2Following is an example of the command output for the show adjacency detail command:
Router# show adjacency detailProtocol Interface AddressIP EOBC0/0 127.0.0.51(4)0 packets, 0 bytesepoch 0sourced in sev-epoch 538Encap length 140000150000000000150000000800ARPIP POS7/1/0 point2point(10)1000 packets, 104000 bytesepoch 0sourced in sev-epoch 538Encap length 40F000800P2P-ADJTAG POS7/1/0 point2point(4)0 packets, 0 bytesepoch 0sourced in sev-epoch 538Encap length 40F008847P2P-ADJIP ATM2/0/0.2 122.0.0.1(14)1000 packets, 108000 bytesepoch 0sourced in sev-epoch 538Encap length 2800010000AAAA030080C20007000000D004F75C0000D004B86C000800ARPTAG ATM2/0/0.2 122.0.0.1(3)0 packets, 0 bytesepoch 0sourced in sev-epoch 538Encap length 2800010000AAAA030080C20007000000D004F75C0000D004B86C008847P2P-ADJOSPF over RBE Configuration Requirements
Cisco IOS Release 12.2(18)SXE and later releases support OSPF over RBE interfaces. To configure OSPF on an RBE interface, observe the following configuration requirements:
•
•
You can turn off MTU checking on the RBE interface by using the ip ospf mtu-ignore command. Use the no ip ospf mtu-ignore command to restore MTU checking.
For detailed information about either of the above commands, see their command descriptions at:
•
•
Sample OSPF over RBE Configuration
Following is a sample configuration for an Ethernet-based CPE that is connected to an RBE interface.
CPE Configuration
interface Ethernet0/0/1.1encapsulation dot1Q 100ip address 20.0.0.1 255.0.0.0ip ospf network point-to-pointip ospf mtu-ignoreRBE (ATM) Interface Configuration
interface atm3/0/0.2 pointip address 20.0.0.2 255.0.0.0ip ospf network point-to-pointip ospf mtu-ignoreatm route-bridge ippvc 10/100Configuring Bridging Control Protocol Support
The Bridging Control Protocol (BCP) Support feature provides support for BCP to Cisco devices, as described in RFC 3518. The Cisco implementation of BCP is a VLAN infrastructure that does not require the use of subinterfaces to group Ethernet 802.1Q trunks and the corresponding PPP links. This approach enables users to process VLAN encapsulated packets without having to configure subinterfaces for every possible VLAN configuration.
The implementation of BCP on the FlexWAN and Enhanced FlexWAN modules includes support for IEEE 802.1Q Virtual LAN (VLAN) and Spanning-Tree Protocol (STP) 802.1D.
Note
The following WAN port adapters support BCP as defined in RFC 3518. For BCP over MLPPP links, see Table 3-1 for a list of port adapters that support the feature.
High Speed Serial Interface (HSSI)
•
•
Packet over Sonet (OC-3)
•
•
•
•
T1/E1
•
•
•
•
•
•
•
•
•
•
•
•
•
T3/E3 (clear-channel and channelized)
•
•
•
•
•
•
•
•
•
Note
Note
For information on configuring BCP, see the next section, "Bridging Control Protocol Modes."
Bridging Control Protocol Modes
BCP operates in two different modes on the FlexWAN and Enhanced FlexWAN modules:
•
•
Trunk Mode BCP
In trunk mode BCP, a single BCP link can carry multiple VLANs. This usage of BCP is consistent with that of normal Ethernet trunk ports.
Usage Guidelines and Restrictions (Trunk-Mode BCP)
When configuring trunk mode BCP, observe the following guidelines and restrictions:
•
–
–
–
–
•
•
•
•
•
•
Note
For information about additional guidelines and restrictions that apply to BCP over MLPPP links, see the "Configuring BCP over MLPPP (Trunk Mode Only)" section.
Configuring Trunk Mode BCP
To configure trunk mode BCP, perform these steps:
The following example shows a trunk mode BCP configuration on a POS interface:
Router(config)# interface p4/1/0Router(config-if)# switchportConfiguring switchport changes encapsulation to PPP automatically.
%Please shut/no shut POS4/1/0 to bring up BCPRouter(config-if)# shutdownRouter(config-if)# no shutdownRouter(config-if)# switchport trunk allowed vlan all%Internal vlans not available for bridging:1006-1018,1021Router(config-if)# ^ZRouter#Router# show run interface p4/1/0Building configuration...Current configuration : 191 bytes!interface POS4/1/0switchportswitchport trunk allowed vlan allswitchport mode trunkThe above is nvgened automatically after switchport is entered.
switchport nonegotiateThe above is nvgened automatically after switchport is entered.
no ip addressencapsulation pppclock source internalendConfiguring BCP over MLPPP (Trunk Mode Only)
The following guidelines apply to BCP over MLPPP links. Note that the guidelines in the "Usage Guidelines and Restrictions (Trunk-Mode BCP)" section also apply for BCP over MLPPP.
•
•
•
•
•
To configure BCP over MLPPP, perform these steps:
Note
BCP over MLPPP Configuration Example
The following commands create a multilink bundle (named Multilink1) and configure the bundle for BCP trunk mode:
Router(config)# interface multilink 1Router(config-if)# switchportRouter(config-if)# switchport trunk allowed vlan 100Router(config-if)# switchport mode trunkRouter(config-if)# switchport nonegotiateRouter(config-if)# no ip addressRouter(config-if)# ppp multilinkRouter(config-if)# shutdownRouter(config-if)# no shutdownRouter(config-if)# exitThe following commands add two serial interfaces to the multilink bundle you just created. The interfaces are located on an OC-3/STM-1 port adapter (PA-MC-STM-1).
Router(config)# interface Serial1/0/0.1/1/1/1:0Router(config-if)# no ip addressRouter(config-if)# encapsulation pppRouter(config-if)# ppp multilinkRouter(config-if)# multilink-group 1!Router(config)# interface Serial1/0/0.1/1/1/2:0Router(config-if)# no ip addressRouter(config-if)# encapsulation pppRouter(config-if)# ppp multilinkRouter(config-if)# multilink-group 1!The following example shows how to remove a member link from the Multilink1 bundle:
Router(config)# interface Serial1/0/0.1/1/1/2:0Router(config-if)# no ppp multilinkRouter(config-if)# no multilink-group 1Verifying Trunk Mode BCP
Because the PPP link has to flap (be brought down and renegotiated), you must run the show command after configuring trunk mode BCP. Note that this requirement also applies to BCP over MLPPP.
The following are examples of trunk mode BCP verification:
Router# show interfaces trunkPort Mode Encapsulation Status Native vlanPO4/1/0 on 802.1q trunking 1Port Vlans allowed on trunkPO4/1/0 1-1005,1025-1026,1028-4094Port Vlans allowed and active in management domainPO4/1/0 1,100,200Port Vlans in spanning tree forwarding state and not prunedPO4/1/0 1,100,200Router# show interfaces switchportName: PO4/1/0Switchport: EnabledAdministrative Mode: trunkOperational Mode: downAdministrative Trunking Encapsulation: dot1qNegotiation of Trunking: OffAccess Mode VLAN: 1 (default)Trunking Native Mode VLAN: 1 (default)Voice VLAN: noneAdministrative private-vlan host-association: noneAdministrative private-vlan mapping: noneAdministrative private-vlan trunk native VLAN: noneAdministrative private-vlan trunk encapsulation: dot1qAdministrative private-vlan trunk normal VLANs: noneAdministrative private-vlan trunk private VLANs: noneOperational private-vlan: noneTrunking VLANs Enabled: 100Pruning VLANs Enabled: 2-1001Capture Mode DisabledCapture VLANs Allowed: ALLUnknown unicast blocked: disabledUnknown multicast blocked: disabledRouter# show interface p4/1/0POS4/1/0 is up, line protocol is upHardware is Packet over SonetMTU 4470 bytes, BW 155000 Kbit, DLY 100 usec,reliability 255/255, txload 1/255, rxload 1/255Encapsulation PPP, crc 16, loopback not setKeepalive set (10 sec)Scramble disabledLCP OpenOpen: BRIDGECP, CDPCPLast input 00:00:05, output 00:00:05, output hang neverLast clearing of "show interface" counters 18:48:09Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0Queueing strategy: fifoOutput queue: 0/40 (size/max)5 minute input rate 1000 bits/sec, 1 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec13161719 packets input, 1145463122 bytes, 0 no bufferReceived 0 broadcasts (0 IP multicast)0 runts, 0 giants, 0 throttles0 parity0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort1685 packets output, 620530 bytes, 0 underruns0 output errors, 0 applique, 30 interface resets0 output buffer failures, 0 output buffers swapped out11 carrier transitionsRouter1#Single-VLAN BCP
Single-VLAN BCP is the access mode in BCP. In this mode, only a single VLAN can be transported on a BCP link.
Usage Guidelines and Restrictions (Single-VLAN BCP)
When configuring single-VLAN BCP, observe the following guidelines and restrictions:
•
•
•
•
•
•
Configuring Single-VLAN BCP
To configure single-VLAN BCP, perform these tasks:
The following example shows a single-VLAN BCP configuration:
Router# show run interface p4/1/0Building configuration...Current configuration : 78 bytes!interface POS4/1/0no ip addressFor BCP ports, the recommendation is not to configure the IP address.
no keepaliveclock source internalendRouter# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# interface p4/1/0Router(config-if)# bridge-domain 100 dot1qMust set encapsulation to PPP before using hw bridging over PPPUnlike switchport, encapsulation is not changed to PPP when bridge-domain is entered.
Router(config-if)# exitRouter(config)# exitRouter(# sho
