FlexWAN and Enhanced FlexWAN Modules Installation and Configuration Guide
FlexWAN and Enhanced FlexWAN Software Features Configuration Information

Table Of Contents

FlexWAN and Enhanced FlexWAN Software Features Configuration Information

Configuring ATM VC Access Trunk Emulation

Supported Port Adapters and Shared Port Adapters

Limitations and Restrictions

ATM VC Access Trunk Emulation Configuration Guidelines

Configuration Tasks

Verifying the Configuration

Configuring Half-Bridging

Configuring Distributed Network-Based Application Recognition

Configuring IP Multicast

Configuring IGMP Snooping

Configuring ACFC and PFC Support on Multilink Interfaces

About ACFC and PFC

Restrictions and Usage Guidelines

Supported Platforms

Enhanced FlexWAN/PA

Configuring ACFC and PFC Support

Configuring ACFC Support

ACFC Configuration Example

Configuring PFC Support

PFC Configuration Example

Configuring Distributed Multilink Point-to-Point Protocol

Restrictions and Usage Guidelines

Port Adapters Supported

Configuration Tasks

Enabling Distributed CEF Switching

Creating a Multilink Bundle

Assigning an Interface to a Multilink Bundle

Disabling PPP Multilink Fragmentation

Verifying the Configuration

Configuring Multilink Frame Relay

Multilink Frame Relay Bundles and Bundle Links

Link Integrity Protocol Control Messages

Load Balancing

Restrictions

Prerequisites

Configuration Tasks

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

Restrictions

Related Features and Technologies

Prerequisites

Configuration Tasks

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 Configuration Examples

LFI over Frame Relay Configuration Example

LFI over ATM Configuration Example

LFI over Leased Line Configuration Example

Monitoring LFI Example

Configuring Compressed Real-Time Protocol (CRTP)

Configuring Distributed CRTP

Restrictions and Usage Guidelines

Prerequisites

Configuration Tasks

Changing the Number of Header Compression Connections

Configuring Voice over Frame Relay (VoFR) FRF.11 and FRF.12

Restrictions and Usage Guidelines

Prerequisites

Configuration Tasks

Configuring Dial Peer Digit Manipulation

Configuring Dial Peer Hunting

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

Troubleshooting Tips

Configuration Examples

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

RBE Configuration Procedure

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

Trunk Mode BCP

Single-VLAN BCP

Dot1q Tunneling

Configuring Multipoint Bridging

Restrictions and Usage Guidelines

Prerequisites

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

Configuration Tasks

Enhancements to RFC 1483 and RFC 1490 Spanning Tree Interoperability

Supported Supervisor Engines and Line Cards

The Interoperability Problem

BPDU Packet Formats

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

Cisco L2PT BPDU Frame Format

BPDU Translation Command Line Interface Summary

The ignore-bpdu-pid Keyword

The pvst-tlv Keyword

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

Configuring Half-Bridging

Configuring Distributed Network-Based Application Recognition

Configuring IP Multicast

Configuring IGMP Snooping

Configuring ACFC and PFC Support on Multilink Interfaces

Configuring Distributed Multilink Point-to-Point Protocol

Configuring Multilink Frame Relay

Configuring Distributed Link Fragmentation and Interleaving for Frame Relay and ATM Interfaces

Configuring Compressed Real-Time Protocol (CRTP)

Configuring Voice over Frame Relay (VoFR) FRF.11 and FRF.12

Configuring Frame Relay Virtual Circuit (VC) Bundling

Configuring Routed Bridged Encapsulation

Configuring Bridging Control Protocol Support

Configuring Multipoint Bridging

Configuring Bridged Routing Encapsulation

Configuring Frame Relay (RFC 1490) Bridging

Enhancements to RFC 1483 and RFC 1490 Spanning Tree Interoperability

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

Supported port adapters: PA-A3-OC3, PA-A3-T3, PA-A3-E3, PA-A6-OC3, PA-A6-T3, and PA-A6-E3

Supported shared port adapters: ATM SPA

Limitations and Restrictions

This feature does not support per-port per VLAN or IGRP snooping.

Supported ATM-specific features depend on the capabilities of the port adapter or shared port adapter.

ATM VC Access Trunk Emulation Configuration Guidelines

Each customer VLAN should be mapped to unique service provider VLANs. A maximum of 32 contiguous customer dot1q tags are supported. For example, in the command bridge-domain 10 dot1q 100, 100 is the base dot1q tag. Thirty-one more dot1q tags can be configured on this PVC with a value of up to 131.

Other bridging modes on the ATM VC cannot be configured if the ATM VC Access trunk Emulation feature is configured, and vice-versa.

Because creating a new subinterface consumes a hidden VLAN on the router, we recommend using a multipoint interface instead of a point-to-point interface.

Configuration Tasks

The VC Access Trunk Emulation configuration tasks are:

Configure the bridge-domain and dot1q ID on the ATM VC.

Verify the new configurations.

Apply QoS by classifying packets based on VLAN ID and priority bits of the dot1q header of the incoming packet.

To configure the bridge-domain and dot1q ID on an ATM VC, use the following procedure:

 
Command
Purpose

Step 1 

Router(config)# interface atm mod_num/bay/port 
multipoint

Specifies the main interface to configure.

Step 2 

Router(config-if)# pvc vpi/vci

Configures a new ATM PVC by assigning virtual path identifier/virtual channel identifier (VPI/VCI) numbers.

Note The VPI/VCI numbers identify the next destination of the ATM cell as it passes through a series of ATM switches on the way to its destination.

Step 3 

Router(config-if-atm-vc)# bridge-domain vlan-id 
dot1q dot1q-id

Binds the PVC to vlan-id based on the dot1q-id value.

Step 4 

Router(config-if-atm-vc)# exit

Exits configuration mode.

In this example, multiple vlan IDs and dot1q IDs are configured:

Router# configure terminal
Enter configuration commands, one per line. end with CNTL/Z.
Router(config)# interface atm3/0/0.2 multipoint
Router(config-if)# pvc1/21
Router(config-if-atm-vc)# bridge-domain 52 dot1q 42
Router(config-if-atm-vc)# bridge-domain 53 dot1q 43
Router(config-if-atm-vc)# bridge-domain 54 dot1q 44
Router(config-if-atm-vc)# bridge-domain 55 dot1q 45
Router(config-if-atm-vc)# bridge-domain 56 dot1q 46
Router(config-if-atm-vc)# exit

Verifying 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 - default

Interface            VCD     VPI      Network     Customer     PVC      Options
                             /VCI     Vlan ID     Dot1Q-ID     Status

ATM3/0/0              1      1/21         52         42          UP     MD
ATM3/0/0              1      1/21         53         43          UP     MD
ATM3/0/0              1      1/21         54         44          UP     MD
ATM3/0/0              1      1/21         55         45          UP     MD
ATM3/0/0              1      1/21         56         46          UP     MD


CBR, SusRate: 2300
AAL5-LLC/SNAP, etype:0x0, Flags: 0x2000820, VCmode: 0x0
OAM frequency: 0 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Disabled
OAM VC status: Not Managed
ILMI VC status: Not Managed
InARP frequency: 15 minutes(s)
Transmit priority 1
InPkts: 0, OutPkts: 745, InBytes: 0, OutBytes: 67795
InPRoc: 0, OutPRoc: 0, Broadcasts: 0
InFast: 0, OutFast: 0, InAS: 0, OutAS:745
InPktDrops: 0, OutPktDrops: 0
InByteDrops: 0, OutByteDrops: 0
CRD Errors: 0, SarTimeOuts: 0, OverSizedSDUs: 0, LengthViolation: 0, CPIErrors: 0
Out CLP=1 Pkts: 0
OAM cells received: 0
F5 InEndloop: 0, F5 OUtSegloop:0, F5 OutRDI: 0
F4 InEndloop: 0, F4 OUtSegloop:0, F4 OutRDI: 0
OAM cell drops: 0
Status: UP
VLAN   Dot1Q   LTL    InPdts   InBytes   InDrops   OutPkts   OutBytes   OutDrops
================================================================================
 52    42      0x4    500      500       0         745        67795       0
 53    43      0x4    500      500       0         745        67795       0
 54    44      0x4    500      500       0         745        67795       0
 55    45      0x4    500      500       0         745        67795       0
 56    46      0x4    500      500       0         745        67795       0

Configuring Half-Bridging


Note Support for this feature exists in Release 12.2(14)SX and later releases.


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:

Half-bridging can be configured at the main interface and subinterface level, but only for multipoint connections.

Only one PVC under a subinterface can be configured for half bridging.

Half bridging is not supported on SVCs.

To configure half-bridging on the FlexWAN or Enhanced FlexWAN module, follow these steps:

 
Command
Purpose

Step 1 

Router(config)# interface atm mod_num/bay/port [.subinterface-number multipoint]

Specifies the subinterface on which to configure half-bridging.

Step 2 

Router(config-subif)# ip address ip-address subnet-mask

Assigns the protocol IP address and subnet mask to the subinterface.

Step 3 

Router(config-subif)# ip mtu bytes

Sets the MTU value for the PVC.

Step 4 

Router(config-subif)# pvc [name] vpi/vci

Configures a new ATM PVC by assigning a name (optional) and VPI/VCI numbers.

Step 5 

Router(config-subif-atm-vc)# encapsulation aal5snap bridge

Configures half-bridging on the PVC.

This example configures half-bridging on a subinterface:

Router(config)# interface atm 3/1/0.2 multipoint
Router(config-subif)# ip address 35.0.0.1 255.0.0.0
Router(config-subif)# ip mtu 1500
Router(config-subif)# pvc 5/100
Router(config-subif-atm-vc)# encapsulation aal5snap bridge

Configuring 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:

Class-Based Marking (the set command)

Class-Based Weighted Fair Queueing (the bandwidth and queue-limit commands)

Low Latency Queueing (the priority command)

Traffic Policing (the police command)

Traffic Shaping (the shape command)

Configure dNBAR as described at the following URL:

http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfnbar_ps1835_TSD_Products_Configuration_Guide_Chapter.html

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 Address and control field compression is only applicable to links that use PPP in HDLC-like framing as described by RFC 1662.


Restrictions and Usage Guidelines

ACFC and PFC should be configured with the link shut down.


Note When Multilink PPP is configured in hardware, ACFC and PFC are active only when all links in the bundle have ACFC and PFC configured.


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:

Channelized T3/DS0 Port Adapter

Channelized T1/E1 Port Adapter

Channelized STM-1 Port Adapter

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:

 
Command
Purpose

Step 1 

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

Router# configure terminal

Enables global configuration mode.

Step 3 

Router(config)# interface serial slot/subslot/port:channel-group

Selects the interface to configure.

slot/subslot/port:channel-group—Specifies the location of the interface.

Step 4 

Router(config-if)# shutdown

Shuts down the interface.

Step 5 

Router(config-if)# ppp acfc remote {apply | reject | ignore}

Configures how the router handles the ACFC option in configuration requests received from a remote peer.

apply—ACFC options are accepted and ACFC may be performed on frames sent to the remote peer.

reject—ACFC options are explicitly ignored.

ignore—ACFC options are accepted, but ACFC is not performed on frames sent to the remote peer.

Step 6 

Router(config-if)# ppp acfc local {request | forbid}

Configures how the router handles ACFC in its outbound configuration requests.

request—The ACFC option is included in outbound configuration requests.

forbid—The ACFC option is not sent in outbound configuration requests, and requests from a remote peer to add the ACFC option are not accepted.

Step 7 

Router(config-if)# no shutdown

Reenables the interface.

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> enable
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface serial 4/1/1/1:0
Router(config-if)# shutdown
Router(config-if)# ppp acfc remote apply
Router(config-if)# ppp acfc local request
Router(config-if)# no shutdown

Configuring PFC Support

To configure PFC support, perform the following tasks in interface configuration mode:

:

 
Command
Purpose

Step 1 

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

Router# configure terminal

Enables global configuration mode.

Step 3 

Router(config)# interface serial slot/subslot/port:channel-group

Selects the interface to configure.

slot/subslot/port:channel-group—Specifies the location of the interface.

Step 4 

Router(config-if)# shutdown

Shuts down the interface

Step 5 

Router(config-if)# ppp pfc remote {apply | reject | ignore}

Configures how the router handles the PFC option in configuration requests received from a remote peer.

apply—PFC options are accepted and PFC may be performed on frames sent to the remote peer.

reject—PFC options are explicitly ignored.

ignore—PFC options are accepted, but PFC is not performed on frames sent to the remote peer.

Step 6 

Router(config-if)# ppp pfc local {request | forbid}

Configures how the router handles PFC in its outbound configuration requests.

request—The PFC option is included in outbound configuration requests.

forbid—The PFC option is not sent in outbound configuration requests, and requests from a remote peer to add the PFC option are not accepted.

Step 7 

Router(config-if)# no shutdown

Reenables the interface.

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> enable
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface serial 4/1/1/1:0
Router(config-if)# shutdown
Router(config-if)# ppp pfc remote reject
Router(config-if)# ppp pfc local forbid
Router(config-if)# no shutdown

Configuring 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 In Cisco IOS Release 12.2SR and later releases, MLPPP links can also be configured to support Bridging Control Protocol (BCP) on the Enhanced FlexWAN module. See the "Configuring BCP over MLPPP (Trunk Mode Only)" section for more information.


Restrictions and Usage Guidelines

The following restrictions apply to the Distributed Multilink PPP feature:


Note Distributed MLPPP is supported only for member links configured at T1/E1 or subrate T1/E1 speeds. Channelized STM-1/T3/T1 interfaces also support dMLPPP at T1/E1 or subrate T1/E1 speeds. Distributed MLPPP is not supported for member links configured at clear-channel T3/E3 or higher interface speeds.


T1 and E1 lines cannot be mixed in a bundle.

T1 lines in a bundle should have the same bandwidth.

All lines in a bundle must reside on the same port adapter.

MLPPP bundles across FlexWAN or Enhanced FlexWAN port adapters are not supported.

Hardware compression is not supported.

Encryption is not supported.

Software compression is not recommended because CPU usage would void performance gains.

The maximum differential delay supported is 50 ms.

Fragmentation is not supported on the transmit side.

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.

Table 3-1 Port Adapters That Support Distributed MLPPP 

Port Adapter Group
Port Adapters Supported

T1/E1 Port Adapters

PA-4T+
PA-8T-V35
PA-8T-X21
PA-8T-232
PA-MC-2E1/120
PA-MC-2T1
PA-MC-4T1
PA-MC-8T1
PA-MC-8E1/120
PA-MC-8TE1+

Channelized T3/E3 Port Adapters

PA-MC-E3
PA-MC-T3
PA-MC-2T3+

STM-1 Port Adapter

PA-MC-STM-1


Configuration Tasks

See the following sections for configuration tasks for the dMLPPP feature.

Enabling Distributed CEF Switching (required)

Creating a Multilink Bundle (required)

Assigning an Interface to a Multilink Bundle (required)

Disabling PPP Multilink Fragmentation (optional)

Verifying the Configuration (optional)

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:

Command
Purpose

Router(config)# ip cef distributed

Enables distributed CEF switching.

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:

 
Command
Purpose

Step 1 

Router(config)# interface multilink group-number

Enters multilink interface configuration mode and creates a multilink bundle (where group-number is a non-zero number to use to identify the bundle).

Step 2 

Router(config-if)# ip address address mask

Assigns an IP address to the multilink interface.

Step 3 

Router(config-if)# encapsulation ppp

Enables PPP encapsulation.

Step 4 

Router(config-if)# ppp multilink

Enables Multilink PPP.

The following is an example of creating a multilink bundle:

interface multilink1
 ip address 10.0.0.0 10.255.255.255
 ppp chap hostname group 1
 ppp multilink
 multilink-group 1

Assigning 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:

 
Command
Purpose

Step 1 

Router(config-if)# no ip address

Removes any specified IP address.

Step 2 

Router(config-if)# keepalive

Sets the frequency of keepalive packets.

Step 3 

Router(config-if)# encapsulation ppp

Enables PPP encapsulation.

Step 4 

Router(config-if)# multilink-group group-number

Assigns the interface to the multilink bundle identified by group-number.

Step 5 

Router(config-if)# ppp multilink

Enables Multilink PPP.

Step 6 

Router(config-if)# ppp authentication chap

(Optional) Enables Challenge Handshake Authentication Protocol (CHAP) authentication.

The following is an example of assigning an interface to a multilink bundle:

interface serial 1/0/0/:2
no ip address
encapsulation ppp
ip route-cache distributed
no keepalive
ppp chap hostname group 1 
ppp multilink
multilink-group 1

Disabling PPP Multilink Fragmentation

By default, PPP multilink fragmentation is enabled. To disable PPP multilink fragmentation, use the following command in interface configuration mode:

Command
Purpose

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 multilink

Multilink1, bundle name is group1 
Bundle is Distributed
0 lost fragments, 0 reordered, 0 unassigned, sequence 0x0/0x0 rcvd/sent
0 discarded, 0 lost received, 1/255 load
Member links:4 active, 0 inactive (max not set, min not set)
Serial1/0/0:1
Serial1/0/0/:2
Serial1/0/0/:3
Serial1/0/0/:4

Configuring 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:

Distributed CEF is limited to IP traffic only.

Frame Relay fragmentation (FRF.12) is not supported.

The Multilink Frame Relay MIB (RFC 3020) is not supported.

FRF.9 hardware compression over multilink Frame Relay is not supported.

Each link in a bundle must reside on the same port adapter and all links in a bundle must have identical configurations. The same bandwidth for each link in the bundle is also recommended because bundles that contain individual links with different bandwidths process packets less efficiently.

Fragmentation is not supported on the transmitting interface when used in conjunction with Distributed Multilink Frame Relay.

The maximum differential delay is 50 ms.

See Table 6-1 for a summary of feature compatibility on distributed multilink Frame Relay interfaces.

Prerequisites

Multilink Frame Relay must be configured on the peer device.

The multilink Frame Relay peer device must not send frames that require assembly.

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 (required)

Configuring a Multilink Frame Relay Bundle Link (required)

Verifying Multilink Frame Relay (optional)

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:

 
Command
Purpose

Step 1 

Router(config)# interface mfr number


Configures a multilink Frame Relay bundle interface.

Step 2 

Router(config-if)# frame-relay multilink bid name


(Optional) Assigns a bundle identification name to a multilink Frame Relay bundle.

Note The bundle identification (BID) is not in effect until the interface has gone from the down state to the up state. One way to bring the interface down and back up again is to use the shut and no shut commands in interface 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:

 
Command
Purpose

Step 1 

Router(config)# interface serial number


Selects a physical interface and enters interface configuration mode.

Step 2 

Router(config-if)# encapsulation frame-relay mfr number [name]


Creates a multilink Frame Relay bundle link and associates the link with a bundle.

Tips To minimize latency that results from the arrival order of packets, we recommend bundling physical links of the same line speed in one bundle.

Step 3 

Router(config-if)# frame-relay multilink lid name


(Optional) Assigns a bundle link identification name to a multilink Frame Relay bundle link.

Note The bundle link identification (LID) is not in effect until the interface has gone from the down state to the up state. One way to bring the interface down and back up again is to use the shut and no shut commands in interface configuration mode.

Step 4 

Router(config-if)# frame-relay multilink hello seconds


(Optional) Configures the interval at which a bundle link will send out hello messages. The default value is 10 seconds.

Step 5 

Router(config-if)# frame-relay multilink ack seconds


(Optional) Configures the number of seconds that a bundle link will wait for a hello message acknowledgment before resending the hello message. The default value is 4 seconds.

Step 6 

Router(config-if)# frame-relay multilink retry number


(Optional) Configures the maximum number of times a bundle link will resend a hello message while waiting for an acknowledgment. The default value is 2 tries.

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 multilink 

Bundle: MFR0, state up, class A, no fragmentation
 ID: Bundle-Dallas
 Serial5/1/0, state up/up, ID: BL-Dallas-1
 Serial5/3/0, state up/add-sent, ID: BL-Dallas-3

Bundle: MFR1, state down, class B, fragmentation
 ID: Bundle-NewYork#1
 Serial3/0/0, state up/up, ID: BL-NewYork-1
 Serial3/2/0, state admin-down/idle, ID: BL-NewYork-2

The 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/2

 Bundle links :
 Serial3/2, HW state :Administratively down, Protocol state :Down_idle, LID :Serial3/2
 Bundle interface = MFR0,  BID = MFR0

The 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 detail
 Bundle links:

  Serial3, HW state = up, link state = Idle, LID = Serial3
  Bundle interface = MFR0,  BID = MFR0
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = Serial5/3, RTT = 0 ms
    Statistics:
    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 = 0

Router# show frame-relay multilink serial3 detail
 Bundle links:

  Serial3, HW state = up, link state = Up, LID = Serial3
  Bundle interface = MFR0,  BID = MFR0
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = Serial5/3, RTT = 4 ms
    Statistics:
    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 = 0

Monitoring 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:

Command
Purpose

Router# debug frame-relay multilink [control [mfr number | serial number]]

Displays debug messages for multilink Frame Relay bundles and bundle links.

Router# show frame-relay multilink [mfr number | serial number] [detailed]


Displays configuration information and statistics about multilink Frame Relay bundles and bundle links.

Router# show interfaces mfr number


Displays information and packet statistics for the bundle interface.


The following example shows the configuration of bundle "MFR1." Serial interfaces 5/0/0 and 6/0/0 are configured as bundle links.

interface MFR1
 frame-relay multilink bid first-bundle
 frame-relay traffic-shaping
 frame-relay class ocean

interface MFR1.1 point-to-point
 ip address 1.1.1.1 255.255.255.0
 frame-relay interface-dlci 100

interface Serial5/0/0
 encapsulation frame-relay MFR1
 frame-relay multilink lid first-link
 frame-relay multilink hello 9
 frame-relay multilink retry 3

interface Serial6/0/0
 encapsulation frame-relay MFR1

 frame-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 Distributed Link Fragmentation and Interleaving for Frame Relay, ATM, and Leased Lines is often referred to as dLFI. This document describes how to configure dLFI on Frame Relay, ATM, and leased lines.


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 Flexwan includes the per-fragment overhead of the MLPPP header for every fragment. On the Cisco 7600 series router, if you apply a QoS policy (with queuing CLI like bandwidth, WRED, shaping or a non-queuing CLI like policing on the egress interface of the MLP bundle having any number of member links in it), the rate and number of packets received can be different in the following situations:
- 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:

Many of the older queueing mechanisms are not supported by dLFI. These mechanisms include:

Fair-queueing on a virtual template interface

Random-detect on a virtual template interface

Custom queueing

Priority queueing


Note Fair queueing, random detection (dWRED), and priority queueing can be configured in a traffic policy using the Modular QoS CLI.


You cannot use dLFI, Compressed Real-Time Transport Protocol (CRTP), and a QoS policy with the priority feature on a multilink interface that contains multiple member links. To use all of these features, the multilink interface can contain only one member link. This is because priority packets do not contain the MLP header and sequence number. On an interface with multiple member links, dLFI distributes priority packets across all of the links in the interface. This means that packets that are compressed by CRTP might arrive out-of-order on an interface with multiple member links; therefore, the packets are dropped (because CRTP cannot decompress them).

Only one member link per MLP bundle is supported when using dLFI over Frame Relay or dLFI over ATM. If more than one link is used in an MLP bundle when using dLFI over Frame Relay or dLFI over ATM, dLFI is automatically disabled. When using dLFI over leased lines, more than one link can be configured with dLFI in the MLP bundle.


Note dLFI over ATM is not supported with multi-point interfaces.


QoS traffic policies will function properly in MLP bundles with more than one link, however.

Only Voice over IP is supported; Voice over Frame Relay and Voice over ATM are not supported.

See Table 6-1 for a summary of feature compatibility with dLFI.

Related Features and Technologies

Frame Relay/ATM interworking (FRF.8)

Distributed Frame Relay fragmentation (FRF.12)

Distributed Multilink Point-to-Point Protocol (dMLP)

The dLFI feature works in conjunction with most Quality of Service (QoS) features, including:

Distributed Low Latency Queueing (dLLQ, the priority command). See the restriction on CRTP and dLFI in the previous section.

Distributed Traffic Shaping (dTS, the shape command).

Distributed Compressed Real-Time Transport Protocol (dCRTP, the ip [rtp | tcp] connections and other compression commands). See the restriction on CRTP and dLFI in the previous section.

Distributed Class-Based Weighted Fair Queueing (dCBWFQ, the bandwidth, fair-queue, and queue-limit commands).

Class-Based Marking (the set command).

Traffic Policing (the police command).

Prerequisites

The following prerequisites apply to dLFI support on the FlexWAN module:

Distributed Low Latency Queueing (dLLQ). The interleaving of packets occurs only when a QoS traffic policy that contains a dLLQ configuration is attached to a PVC or an interface. If dLLQ is not configured on the PVC or interface, packets will be fragmented but not interleaved.

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.

A virtual template or a multilink interface must be shutdown and then re-enabled (using the shutdown command followed by the no shutdown command) to change any PPP configuration. The exception to this restriction is the QoS traffic policy, which does not require the shutdown/no shutdown sequence in order to be enabled.

All currently available serial port adapters for the FlexWAN support LFI using MLP over Frame Relay:

PA-4T+

PA-8T

PA-MC-T3

PA-MC-2T3+

PA-MC-4T1

PA-MC-8E1/120

PA-MC-8T1

PA-MC-E3

PA-MC-STM1

HSSI

PA-H

PA-2H

MLP over ATM requires a PA-A3 ATM port adapter. The following PA-A3 ATM port adapters support LFI using MLP over ATM:

PA-A3-E3

PA-A3-OC3

PA-A3-T3


Note The dLFI feature does not support the PA-A3 IMA port adapter.


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. Required for configuring dLFI on Frame Relay. Not available on Cisco IOS Release 12.0 S.

Configuring LFI Using MLP over ATM. Required for configuring dLFI on ATM. Not available on Cisco IOS Release 12.0 S.

Configuring LFI Using MLP over a Leased Line. Required for configuring dLFI on leased lines.

Verifying LFI for Frame Relay, ATM, or Leased Lines. Optional.

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

Configuring LFI Using MLP on a Virtual Template Interface

Associating the Virtual Template Interface with a Frame Relay PVC

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:

 
Command
Purpose

Step 7 

Router(config)# class-map [match-any | match-all] 
class-map-name 

Specifies the user-defined name of the traffic class and enters class map configuration mode. A traffic class is used to classify traffic.

Step 8 

Router(config-cmap)# match match-criterion

Specifies the criteria to use to classify traffic. Traffic that matches the specified criteria is considered part of this traffic class.

Multiple match criterion can be specified in a single traffic class.

Step 9 

Router(config-cmap)# exit

Exits class map configuration mode.

Step 10 

Router(config)# policy-map policy-name

Specifies the name of the QoS traffic policy to configure and enters policy map configuration mode.

Step 11 

Router(config-pmap)# class class-map-name

Specifies the name of a predefined traffic class to include in the service policy. This traffic class classifies traffic; the QoS features configured in the traffic policy determine how to forward traffic that matches the traffic class configuration.

In these instructions, the class-map-name option should match the class-map-name entered in Step 1 of this procedure.

Step 12 

Router(config-pmap-c)# priority [percent] [kpbs | 
percent] [bytes]

Reserves a priority queue with a specified amount or percent of available bandwidth for high-priority traffic.

The priority command is used to enable dLLQ.

Step 13 

Router(config-pmap-c)# 

Enables a QoS feature in the traffic policy.

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:

 
Command
Purpose

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 For dLFI, the QoS traffic policy is attached to the virtual template. The policy need not be attached to the Frame Relay map class. Use the service-policy command to attach the policy.

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 For dLFI, the QoS traffic policy is attached to the virtual template. The policy need not be attached to the Frame Relay map class. Use the service-policy command to attach the policy.

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:

 
Command
Purpose

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

Configuring LFI Using MLP in a Virtual Template Interface

Associating the Virtual Template Interface with an ATM PVC

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:

:

 
Command
Purpose

Step 1 

Router(config)# class-map [match-any | match-all] 
class-map-name 

Specifies the user-defined name of the traffic class and enters class map configuration mode. A traffic class is used to classify traffic.

Step 2 

Router(config-cmap)# match match-criterion

Specifies the criteria to classify traffic against. If traffic matches the specified match criteria, traffic is said to belong to the traffic class.

Multiple match criterion can be specified in a single traffic class.

Step 3 

Router(config-cmap)# exit

Exits class map configuration mode.

Step 4 

Router(config)# policy-map policy-name

Specifies the name of the QoS traffic policy to configure and enters policy map configuration mode.

Step 5 

Router(config-pmap)# class class-map-name

Specifies the name of a predefined class included in the service policy. This traffic class classifies traffic; the QoS features configured in the traffic policy determine how to forward traffic that matches the traffic class configuration.

In these instructions, the class-map-name option should match the class-map-name entered in Step 1 of this procedure.

Step 6 

Router(config-pmap-c)# priority [percent] [kpbs | 
percent] [bytes]

Reserves a priority queue with a specified amount or percentage of available bandwidth for high-priority traffic.

The priority command is used to enable dLLQ.

Step 7 

Router(config-pmap-c)# 

Enables a QoS feature in the traffic policy.

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:

 
Command
Purpose

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 For dLFI, the QoS traffic policy that is attached using the service-policy command is attached to the virtual template. The QoS traffic policy does not have to be attached to the ATM PVC.

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 For dLFI, the QoS traffic policy that is attached using the service-policy command is attached to the virtual template. The QoS traffic policy does not have to be attached to the ATM PVC.

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:

 
Command
Purpose

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

Assigning an Interface to a Multilink Bundle

Configuring the Channel Group

Creating a Multilink Group

Assigning an Interface to a Multilink Group

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:

 
Command
Purpose

Step 1 

Router(config)# class-map [match-any | match-all] 
class-map-name 

Specifies the user-defined name of the traffic class and enters class map configuration mode. A traffic class is used to classify traffic.

Step 2 

Router(config-cmap)# match match-criterion

Specifies the criteria to classify traffic against. If traffic matches the specified match criteria, traffic is said to belong to the traffic class.

Multiple match criterion can be specified in a single traffic class.

Step 3 

Router(config-cmap)# exit

Exits class map configuration mode.

Step 4 

Router(config)# policy-map policy-name

Specifies the name of the QoS traffic policy to configure and enters policy map configuration mode.

Step 5 

Router(config-pmap)# class class-map-name

Specifies the name of a predefined class included in the service policy. This traffic class classifies traffic; the QoS features configured in the traffic policy determine how to forward traffic that matches the traffic class configuration.

In these instructions, the class-map-name option should match the class-map-name entered in Step 1 of this procedure.

Step 6 

Router(config-pmap-c)# priority [percent] [kpbs | 
percent] [bytes]

Reserves a priority queue with a specified amount or percentage of available bandwidth for high-priority traffic.

The priority command is used to enable dLLQ.

Step 7 

Router(config-pmap-c)# 

Enables a QoS feature in the traffic policy.


Note The bandwidth command can be used in a QoS traffic policy to specify an amount of bandwidth to be reserved for the traffic policy. If the bandwidth command is used in a traffic policy that will be attached to a multilink interface, the following guidelines should be followed:

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:

 
Command
Purpose

Step 1 

Router(config)# controller [t1 | e1] slot/port

Configures a T1 or E1 controller.

Step 2 

Router(config-controller)# channel-group 
channel-number timeslots range [speed {48 | 56 | 64}]

Defines the time slots that belong to each T1 or E1 circuit.

Creating a Multilink Group

To create a multilink group, use the following commands beginning in interface configuration mode:

 
Command
Purpose

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 For dLFI, the QoS traffic policy that is attached using the service-policy command is entered in the multilink group. The QoS traffic policy does not have to be attached to the serial interface that is part of the group.

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 For dLFI, the QoS traffic policy that is attached using the service-policy command is entered in the multilink group. The QoS traffic policy does not have to be attached to the serial interface that is part of the group.

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:

 
Command
Purpose

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:

Command
Purpose

Router# show frame-relay pvc dlci

Displays statistics about PVCs for Frame Relay interfaces.

Router# show interfaces

Displays interleaving statistics. Interleaving data is displayed only if interleaving occurs.

Router# show ppp multilink

Displays bundle information for the MLP bundles and their PPP links in the router.

Router# show policy-map interface

Displays configurations and statistics of all input and output traffic policies attached to an interface.


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:

Command
Purpose

Router# show ppp multilink

Displays bundle information for the MLP bundles and their PPP links in the router. Displays dLFI statistics, including the number of fragmented, unfragmented, and reassembled packets, reassembly and fragmentation drops, and fragments that arrived out of sequence.

Router# debug ppp multilink fragments

Displays information about individual multilink fragments and important multilink events.

Router# debug voice RTP

Displays information about the interleaving of voice and data packets.



Note The debug ppp multilink fragments and debug voice RTP commands have memory overhead and should not be used when memory is scarce or when traffic is very high.


LFI Configuration Examples

This section provides the following configuration examples:

LFI over Frame Relay Configuration Example

LFI over ATM Configuration Example

LFI over Leased Line Configuration Example

Monitoring LFI Example

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 voip
  match ip precedence 5

class-map business
  match ip precedence 3


policy-map llq-policy
  class voip
    priority 32
  class business
    bandwidth 32


policy-map shape-llq-policy
  class class-default
    shape average 80000 320 320
    service-policy llq-policy


policy-map input-policy
  class voip
    police 32000 1500 1500 conform-action transmit exceed-action drop


controller T1 5/1/0
  framing esf
  linecode b8zs
  channel-group 0 timeslots 1-2


interface Serial5/1/0:0
  no ip address
  encapsulation frame-relay


interface Serial5/1/0:0.1 point-to-point
  frame-relay interface-dlci 20 ppp Virtual-Template2

interface Virtual-Template2
  bandwidth 78
  ip address 98.0.0.2 255.0.0.0
  no keepalive
  service-policy output llq-policy
  service-policy input input-policy
  ppp multilink
  ppp multilink fragment-delay 8
  ppp multilink interleave

LFI 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 voip
match ip precedence 5

class-map business
match ip precedence 3

policy-map llq-policy
class voip
priority 32
class business
bandwidth 32

policy-map input-policy
class voip
police 32000 1500 1500 conform-action transmit exceed-action drop

interface ATM4/0/0
no ip address
no atm ilmi-keepalive

interface ATM4/0/0.1 point-to-point
pvc 0/34 
abr 100 80
protocol ppp Virtual-Template4

interface Virtual-Template4
bandwidth 78
ip address 88.0.0.2 255.0.0.0
service-policy output llq-policy
service-policy input input-policy
ppp multilink
ppp multilink fragment-delay 8
ppp multilink interleave

LFI 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 voip
match ip precedence 5

class-map business
match ip precedence 3

policy-map llq-policy
class voip
priority 32
class business
bandwidth 32

policy-map input-policy
class voip
police 32000 1500 1500 conform-action transmit exceed-action drop

controller T1 5/1/0
channel group 0 timeslots 1-2

interface multilink 2
ip address 172.16.0.0 255.0.0.0
keepalive 5
bandwidth 128
ppp multilink
ppp multilink fragment-delay 8
ppp multilink interleave
service-policy output llq-policy
service-policy input input-policy
multilink-group 2

interface serial5/0/0:0
no ip address
encapsulation ppp
keepalive 5
ppp chap hostname G2
ppp multilink
multilink-group 2

Monitoring 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 multilink 
Multilink11, bundle name is G11 
Bundle is Distributed 
0 lost fragments, 0 reordered, 0 unassigned 
0 discarded, 0 lost received, 1/255 load 
0x0 received sequence, 0x14 sent sequence 
Member links:2 active, 0 inactive (max not set, min not set) 
Serial4/1/1:2, no frags rcvd  64 weight, 2 max fragments 
Serial4/1/1:3, no frags rcvd  64 weight, 2 max fragments 
dLFI statistics:
            DLFI Packets    Pkts In   Chars In   Pkts Out  Chars Out 
              Fragmented      20        1372        20       1372 
            UnFragmented       0         0          0          0   
             Reassembled       2         1228       2        1228 
        Reassembly Drops       0 
     Fragmentation Drops       0 
        Out of Seq Frags       0 

Configuring 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.

Table 3-2 Port Adapters That Support CRTP 

Port Adapter Group
Port Adapters Supported

T1/E1 Port Adapters

PA-4T+
PA-8T-V35
PA-8T-X21
PA-8T-232
PA-MC-2E1/120
PA-MC-2T1
PA-MC-4T1
PA-MC-8T1
PA-MC-8E1/120
PA-MC-8TE1+
PA-MC-STM-1

T3/E3 Clear-Channel and Channelized Port Adapters

PA-T3
PA-2T3
PA-T3+
PA-2T3+
PA-E3
PA-2E3
PA-MC-T3
PA-MC-2T3+
PA-MC-E3


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

This feature is not available for Async and Dialer interfaces.

You cannot use dLFI, Compressed Real-Time Transport Protocol (CRTP), and a QoS policy with the priority feature on a multilink interface that contains multiple member links. To use all of these features, the multilink interface can contain only one member link. This is because priority packets do not contain the MLP header and sequence number. On an interface with multiple member links, dLFI distributes priority packets across all of the links in the interface. This means that packets that are compressed by CRTP might arrive out-of-order on an interface with multiple member links; therefore, the packets are dropped (because CRTP cannot decompress them).

When distributed fast-switching is enabled, the detail option is not available with the show ip rtp header-compression and show ip tcp header-compression commands. Users who need the detailed information for either of these commands can retrieve this information by disabling distributed fast-switching and then entering the show ip rtp header-compression detail or show ip tcp header-compression detail commands.

This restriction affects Multilink PPP interfaces that use link fragmentation and interleaving (LFI). In this case, if RTP header compression is configured, RTP packets originating on or destined to the router will be fast-switched if the link is limited to one channel. If the link has more than one channel, the packets will be process-switched.

Prerequisites

For this feature to work, the following prerequisites must be met:

High-level Data Link Control (HDLC), PPP, or Frame Relay encapsulation must be configured.

TCP or RTP header compression, or both, must be enabled.

For information on configuring RTP header compression, see the Configuring Compressed Real-Time Protocol document online or on the documentation CD-ROM.

For information on configuring TCP header compression, see the "Compress TCP Packet Headers" section of the Configuring IP Services document online or on the documentation CD-ROM.

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 (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:

Command
Purpose

ip tcp compression-connections number

Specifies the total number of TCP header compression connections supported on the interface.

ip rtp compression-connections number

Specifies the total number of RTP header compression connections supported on the interface.


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 header
RTP/UDP/IP header compression statistics:
   Interface Serial4/1/1:
   Distributed fast switched:
   8 seconds since line card sent last stats update
     Rcvd:   0 total, 0 compressed, 0 errors
              0 dropped, 0 buffer copies, 0 buffer failures
     Sent:   0 total, 0 compressed, 
              0 bytes saved, 0 bytes sent
     Connect:16 rx slots, 16 tx slots, 
              0 long searches, 0 misses 0 collisions

The 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 header
TCP header compression statistics:
   Interface Serial4/1/1:
   Distributed fast switched:  
     8 seconds since line card sent last stats update
     Rcvd:   0 total, 0 compressed, 0 errors
              0 dropped, 0 buffer copies, 0 buffer failures
     Sent:   0 total, 0 compressed, 
              0 bytes saved, 0 bytes sent
     Connect: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 The Cisco 7600 series router and Catalyst 6500 series switch do not support voice modules; therefore, the router or switch can act only as a VoFR tandem switch when FRF.11 or FRF.12 is configured on the FlexWAN or Enhanced FlexWAN module.


Restrictions and Usage Guidelines

To implement VoFR between a Cisco MC3810 and a FlexWAN or Enhanced FlexWAN module on a Cisco 7600 router or Catalyst 6500 switch, the Cisco MC3810 must be running Cisco IOS Release 12.0(3)XG or Release 12.0(4)T or later.

A FlexWAN or Enhanced FlexWAN module cannot terminate calls initiated by a Cisco MC3810 that is using a VoFR implementation prior to Cisco IOS Release 12.0(3)XG or Release 12.0(4)T.

It is currently not possible to translate from the Voice Over IP (VoIP) transport protocol to other protocols such as VoFR. As a result, a call coming in on a VoIP connection is not (tandem) switched to a VoFR connection.

Hookflash for dial-tone recall from the router is not supported. However, the router can pass-through hookflash on FXO-FXS permanent connections and E&M-E&M connections using the connection trunk voice port configuration command.

For a FlexWAN or Enhanced FlexWAN module on a Cisco 7600 router, distributed Cisco Express Forwarding (dCEF) must be enabled to run FRF.11 and FRF.12.

When using the shape command, the cir value needs to be a multiple of 8000. The bc/cir and be/cir must be multiples of 4 ms.

Cisco MC3810 concentrators running Cisco IOS releases prior to Release 12.0(3)XG or Release 12.0(4)T cannot tandem VoFR calls from non-Cisco MC3810 access concentrators, including a FlexWAN or Enhanced FlexWAN module.

Voice over ATM Switched Virtual Circuits (SVCs) are not supported.

Prerequisites

Before you can configure Voice over Frame Relay, you must do the following:

Complete your company's dial plan.

Establish a working Frame Relay network. For more information about configuring Frame Relay, refer to Cisco IOS Wide-Area Networking Configuration Guide, Release 12.2:

http://www.cisco.com/en/US/docs/ios/12_2/wan/configuration/guide/fwan_c.html

Establish a working telephony network based on your company's dial plan:

Integrate your dial plan and telephony network into your existing Frame Relay network topology. Make routing and dialing transparent to the user—for example, avoid secondary dial tones from secondary switches where possible.

Contact your PBX vendor for instructions about how to reconfigure the appropriate PBX interfaces.

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:

Configuring Dial Peer Digit Manipulation. Required.

Configuring Dial Peer Hunting. Required.

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

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:

 
Command
Purpose

Step 1 

Router(config)# dial-peer voice tag pots

Enters dial peer configuration mode for a POTS dial peer.

Step 2 

Router(config-dial-peer)# forward-digits {num-digit | 
all | extra}

or

Router(config-dial-peer)# default forward-digits

or

Router(config-dial-peer)# no forward-digits

If using the forward-digits feature, configures the digit-forwarding method. The range for the number of digits forwarded (num-digit) is 0 through 32.

In the default condition, dialed digits not matching the destination pattern are forwarded.

Note The no state is not the default state.

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:

 
Command
Purpose

Step 1 

Router(config)# dial-peer hunt hunt-order-number

Specifies the hunt selection order for dial peers.

Step 2 

Router(config)# dial-peer terminator character

(Optional) Designates a special character to be used as a terminator for variable-length dialed numbers.

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:

 
Command
Purpose

Step 1 

Router(config)# dial-peer voice tag {pots | vofr}

Enters dial peer configuration mode for the specified dial peer.

Step 2 

Router(config-dial-peer)# huntstop

Disables dial peer hunting on the dial peer. Once you enter this command, no further hunting is allowed if a call fails on the specified dial peer.

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:

 
Command
Purpose

Step 1 

router(config)# class-map class-map-name

Creates a class map that will be assigned to a group of Permanent Virtual Circuits (PVCs). The map class name must be unique.

Step 2 

router(config-class-map)# match protocol vofr

Specifies Voice over Frame Relay packets as a matching criterion.

Step 3 

router(config-class-map)# exit

Exits class map configuration mode.

Step 4 

router(config)# policy-map policy-map-name

Specifies the name of the service policy to configure.

Step 5 

router(config-pmap-c)# class class-map-name

Specifies the name of a predefined class, which was defined with the class-map command, included in the service policy. In this particular example, the class-map-name might have been specified in Step 1.

Step 6 

router(config-pmap-c)# priority kpbs

Specifies low latency service (in kbps) for priority traffic. Packets with low latency service are given preferential treatment and transmitted before the packets of any other traffic classes in congested environments.

Step 7 

router(config-pmap-c)# exit

Exits policy map class configuration mode.

Step 8 

router(config-pmap)# exit

Exits policy map configuration mode.

Step 9 

router(config)# policy-map policy-map-name

Specifies the name of a new service policy to configure. The policy map name should be different for this service policy.

Step 10 

router(config-pmap)# class class-default

Specifies the default traffic class as the associated traffic class.

Step 11 

router(config-pmap-c)# shape average bc cir

Specifies the shaping parameters for the traffic policy. These shaping parameters will eventually be used in the map class.

Step 12 

router(config-pmap-c)# service-policy policy-map-name

Specifies the previously-defined service policy to configure as part of this service policy. The policy map name for this step was defined in step 4 of this procedure.

Step 13 

router(config)# map-class frame-relay map-class-name

Creates a map class name that will be assigned to a group of PVCs. The map class name must be unique.

Step 14 

router(config-map-class)# frame-relay fragment 
fragment-size

Configures Frame Relay fragmentation for the map class. The fragment_size defines the payload size of a fragment, and excludes the Frame Relay headers and any Frame Relay fragmentation header. The valid range is from 16 to 1600 bytes, and the default is 53.

The fragment_size should be less than or equal to the maximum transmission unit (MTU) size.

Set the fragmentation size such that the largest data packet is not larger than the voice packets.

Step 15 

router(config-map-class)# service-policy output 
policy-map-name

Specifies the name of the service policy to be attached to the interface. The policy map name was specified in step 9 of this procedure.

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:

Configuring Switched Calls (User-Dialed or Auto-Ringdown)

Configuring Cisco-Trunk Permanent (Private Line) Calls

Configuring FRF.11 Trunk (Private Line) Calls

In addition, special consideration is required for configuring calls for tandem nodes. For more information, see the "Configuring Connections for Tandem Nodes" section.


Note Use of Cisco-trunks for permanent calls (private line) is recommended over FRF.11-trunk calls unless FRF.11-compliant standards-based interworking is required with non-Cisco devices. The Cisco-trunk protocol is a superset of the FRF.11 protocol and contains Cisco proprietary extensions designed to support switched call routing and other advanced features.


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 

Type of Call
Frame Relay DLCI Interface Command to Enter
Data Fragmentation Supported by VoFR Command
Session Protocol Command to Enter in Dial Peer Mode
Voice Port Connection Command to Enter

Switched call
(user-dialed or auto-ringdown) to other routers supporting VoFR

vofr [data cid]
[call-control [cid]]1

FRF.11 Annex C

session protocol cisco-switched2

For user-dialed calls: none

For auto-ringdown calls:
connection plar destination-string

Switched call
(user-dialed or auto-ringdown)
to a Cisco MC3810 running
Cisco IOS Releases before 12.1(2)T

vofr cisco3

Cisco  proprietary4

session protocol cisco-switched

For user-dialed calls: none

For auto-ringdown calls:
connection plar destination-string

Cisco-trunk
permanent call
(private line) to other routers supporting VoFR

vofr data cid
call-control cid

FRF.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)T

vofr 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

Configuring Switched Calls to a Cisco MC3810 Running Cisco IOS Releases Before 12.1(2)T

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:

 
Command
Purpose

Step 1 

Router(config-if)# frame-relay interface-dlci dlci

Configures the Frame Relay DLCI and enters DLCI configuration mode.

Step 2 

Router(config-if)# vofr [data cid] [call-control 
[cid]]

Configures the Frame Relay DLCI to support VoFR and sets the data and call-control Channel IDs (CIDs).

The recommended setting for this command is vofr data 4 call-control 5.

Note If you use the vofr command, all subchannels on the DLCI are configured for FRF.11 encapsulation. If you enter the vofr command without any keywords or arguments, the data subchannel is CID 4 and there is no call-control subchannel.

If you are configuring user-dialed calls, this procedure is completed. If you are configuring auto-ringdown calls, proceed to the next step.

Step 3 

Router(config)# voice-port slot/port:ds0-group

Identifies the voice port you want to configure and enters voice port configuration mode.

Step 4 

Router(config-voiceport)# connection plar 
destination-string

(Optional) For auto-ringdown calls, configures the private line automatic ringdown (PLAR) connection, specifying the telephone number in the destination-string.

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 A FlexWAN or Enhanced FlexWAN module on a Cisco 7600 router cannot terminate or initiate calls with a Cisco MC3810 running software releases before Cisco IOS Release 12.0(3)XG and Release 12.0(4)T.


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:

 
Command
Purpose

Step 1 

Router(config-if)# frame-relay interface-dlci dlci

Configures the Frame Relay DLCI and enters DLCI configuration mode.

Note The voice-encap option of the frame-relay interface-dlci command on the Cisco MC3810 is no longer supported beginning in this release.

Step 2 

Router(config-if)# vofr cisco

Configures the Frame Relay DLCI to support VoFR and the Cisco proprietary fragmentation implementation.

When this command is entered, data CID 4 and call-control CID 5 are automatically assigned.

If you are configuring user-dialed calls, this procedure is complete. If you are configuring auto-ringdown calls, proceed to the next step.

Step 3 

Router(config)# voice-port slot/port:ds0-group

Identifies the voice port being configured and enters voice port configuration mode.

Step 4 

Router(config-voiceport)# connection plar 
destination-string

(Optional) For auto-ringdown calls, configures the PLAR connection, specifying the telephone number in the destination-string.

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

Configuring Cisco-Trunk Permanent Calls

Configuring Cisco-Trunk Permanent Calls to a Cisco MC3810 Running Cisco IOS Releases Before 12.1(2)T

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:

casUse the cas option to support North American channel-associated signalling (CAS)/robbed-bit signaling. This is the default signaling type.

ceptUse the cept option to provide a basic E1 ABCD protocol, primarily for CEPT Ear and Mouth (E&M) signaling. This option is primarily used for European voice networks. If this option is used with FXS or FXO voice ports, the signaling used is equivalent to Mercury Exchange Limited (MEL) CAS.

ext-signal—Use the ext-signal option in cases where some external signaling channel is being used (for example, common channel signaling), or where no signaling information is being sent at all over a permanent "dumb" voice pipe. Applications where no signaling is required include using a simple voice pipe to carry audio for a public address system.

transparent—Use the transparent option when the ABCD signaling bits are copied through from the T1/E1 interface "transparently" without modification or interpretation (also known as transparent FRF.11 signaling). This allows the router to handle or transport unknown signaling protocols.

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:

 
Command
Purpose

Step 1 

Router(config)# dial-peer voice number vofr

Defines a VoFR dial peer and enters dial peer configuration mode. All subsequent commands that you enter in dial peer voice mode before you exit will apply to this dial peer.

The number tag value identifies the dial peer and must be unique on the router. Do not duplicate a specific tag number.

Step 2 

Router(config-dial-peer)# destination-pattern string

Configures the dial peer's destination pattern. The same restrictions for the string listed in the POTS dial peer configuration also apply to the VoFR destination pattern.

Step 3 

Router(config-dial-peer)# session target interface 
dlci [cid]

Configures the Frame Relay session target for the dial peer.

Step 4 

Router(config-dial-peer)# session protocol 
cisco-switched 

Configures the session protocol to support switched calls.

This is the default setting, and entering this command is not required.

Step 5 

Router(config-dial-peer)# codec type [bytes bytes]

Specifies the voice coder rate of speech and payload size for the dial peer. The default dial peer codec is g729r8. Note that the Cisco MC3810 is limited to a maximum of 12 calls when using g729r8; to support up to 24 calls on the Cisco MC3810, use g729ar8.

Specifying the payload size by entering the bytes value is optional. Each codec type defaults to a different payload size if you do not specify a value. To obtain a list of the default payload sizes, enter the codec command and the bytes option followed by a question mark (?).

Note On the Cisco MC3810, you can also assign codec values to the voice port. When you configure the codec type for regular switched voice calls, you must set the codec type on the Cisco MC3810 voice port. When you configure the codec for permanent calls (cisco-trunk and frf11-trunk), you must configure the codec type on the dial peer. You cannot specify the payload size on the voice port.

Step 6 

Router(config-dial-peer)# dtmf-relay

(Optional) If the codec type is a low bit-rate codec such as g729 or g723, specifies support for dial-tone multifrequency (DTMF) relay to improve end-to-end transport of DTMF tones. DTMF tones do not always propagate reliably with low bit-rate codecs.

DTMF relay is disabled by default.

Step 7 

Router(config-dial-peer)# signal-type 
{cas | cept | ext-signal | transparent}

Defines the type of ABCD signaling packets that are generated by the voice port and sent to the data network.

Enter cas to support CAS. Enter cept to support the European CEPT standard (related to MEL CAS).

Enter ext-signal to indicate that ABCD signaling packets should not be sent for configurations where the line signaling information is carried externally to the voice port.

Enter transparent (for digital T1/E1 interfaces) to read the ABCD signaling bits directly from the T1/E1 interface without interpretation, and to pass them transparently to the data network (this is also known as transparent FRF.11 signaling).

Step 8 

Router(config-dial-peer)# no vad

(Optional) Disables voice activity detection (VAD) on the dial peer. This command is enabled by default.

Step 9 

Router(config-dial-peer)# sequence-numbers 

(Optional) Enables the voice sequence number if required for your configuration. This command is disabled by default.

Step 10 

Router(config-dial-peer)# preference value

(Optional) Configures a preference for the VoFR dial peer. The value is a number from 0 through 10 where the lower the number, the higher the preference in hunt groups.

Step 11 

Router(config-dial-peer)# fax rate {2400 | 4800 | 7200 | 
9600 | 14400 | disable | voice}

(Optional) Configures the transmission speed (in bps) at which a fax will be sent to the dial peer.

The default is voice, which specifies the highest possible transmission speed allowed by the voice rate.

Step 12 


To configure another VoFR dial peer, exit dial peer configuration mode and repeat steps 1 through 11.

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 If you are configuring Cisco-trunk permanent calls to Cisco MC3810 concentrators running Cisco IOS releases before 12.1(2)T, see the "Configuring Cisco-Trunk Permanent Calls to a Cisco MC3810 Running Cisco IOS Releases Before 12.1(2)T" section.


To configure Cisco-trunk permanent calls, use the following commands from interface configuration mode:

 
Command
Purpose

Step 1 

Router(config-if)# frame-relay interface-dlci dlci

Configures the Frame Relay DLCI and enters DLCI configuration mode.

Step 2 

Router(config-if)# vofr [data cid] [call-control 
[cid]]

Configures the Frame Relay DLCI to support VoFR.

Note When you enter the vofr command, all subchannels on the DLCI are configured for FRF.11 encapsulation. If you enter the vofr command without any keywords or arguments, the data subchannel is CID 4 and there are no call-control subchannels.

If you are configuring tandem calls, this step ends your configuration.

Step 3 

Router(config)# voice-port slot/port:ds0-group

Identifies the voice port to configure and enters voice port configuration mode.

Step 4 

Router(config-voiceport)# connection trunk 
destination-string [answer-mode]

For private line calls, configures the trunk connection by specifying the telephone number in the destination-string.

When configuring Cisco-trunk permanent calls, one side must be the call initiator (master) and the other side is normally the call answerer (slave). By default, the voice operates in master mode. Enter the answer-mode keyword to specify that the voice port operates in slave mode.

Step 5 

Router(config-voiceport)# shutdown

Shuts down the voice port.

Step 6 

Router(config-voiceport)# no shutdown

Reactivates the voice port to enable the trunk connection to take effect.

This configuration uses standard FRF.11 Annex C fragmentation.


Note Every time you enter the connection trunk or no connection trunk command, you must toggle the voice port (by entering shutdown, then no shutdown) for the changes to take effect.


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:

 
Command
Purpose

Step 1 

Router(config-if)# frame-relay interface-dlci dlci

Configures the Frame Relay DLCI and enters DLCI configuration mode.

Step 2 

Router(config-if)# vofr cisco

Configures the Frame Relay DLCI to support VoFR and the Cisco proprietary data implementation.

When this command is entered, data CID 4 and call-control CID 5 are automatically assigned.

Step 3 

Router(config)# voice-port slot/port:ds0-group

Identifies the voice port to configure and enters voice port configuration mode.

Step 4 

Router(config-voiceport)# connection trunk 
destination-string [answer-mode]

For private line calls, configures the trunk connection by specifying the telephone number in destination-string.

When configuring Cisco-trunk permanent calls, one side must be the call initiator (master) and the other side is normally the call answerer (slave). By default, the voice operates in master mode. Enter the answer-mode keyword to specify that the voice port should operate in slave mode.

Step 5 

Router(config-voiceport)# shutdown

Shuts down the voice port.

Step 6 

Router(config-voiceport)# no shutdown

Reactivates the voice port to enable the trunk connection to take effect.

This configuration uses Cisco proprietary data fragmentation.


Note Every time you enter the connection trunk or no connection trunk command, you must toggle the voice port (by entering shutdown, then no shutdown) for the changes to take effect.


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 This configuration requires that you set the session protocol dial peer configuration command to frf11-trunk.


To configure FRF.11 trunk (private line) calls, enter the following commands from interface configuration mode:

 
Command
Purpose

Step 1 

Router(config-if)# frame-relay interface-dlci dlci

Configures the Frame Relay DLCI and enters DLCI configuration mode.

Step 2 

Router(config-if)# vofr [data cid] [call-control cid]

Configures the Frame Relay DLCI to support VoFR and to optionally enter the data and call-control CIDs.

Step 3 

Router(config)# voice-port slot/port:ds0-group

Identifies the voice port to configure and enters voice port configuration mode.

Step 4 

Router(config-voiceport)# connection trunk 
destination-string [answer-mode]

For private line calls, configures the trunk connection by specifying the telephone number in the destination-string.

When configuring FRF.11 trunk calls, one side must be the call initiator (master) and the other side is normally the call answerer (slave). By default, the voice port is the master. Enter the answer-mode keyword to specify that the voice port is the slave.

This configuration uses FRF.11 Annex C data fragmentation.


Note Every time you enter the connection trunk or no connection trunk command, you must toggle the voice port (by entering shutdown, then no shutdown) for the changes to take effect.


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.

Table 3-4 Supported VoFR End Node and Tandem Node Combinations

End Nodes
Tandem Node
VoFR Command to Enter for the Frame Relay DLCI

Cisco 2600, Cisco 3600, Cisco MC3810, Cisco 7200, Cisco 7500, or FlexWAN or Enhanced FlexWAN module on Cisco 7600

Cisco 2600, Cisco 3600, Cisco MC3810, Cisco 7200, Cisco 7500, or FlexWAN or Enhanced FlexWAN module on Cisco 7600

vofr call-control

Cisco MC3810 running
Cisco IOS releases
earlier than 12.1(2)T

Cisco 2600, Cisco 3600, Cisco 7200, Cisco 7200, or FlexWAN or Enhanced FlexWAN module on Cisco 7600

vofr cisco


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 Pick up the handset on a telephone connected to the configuration and verify that you can get a dial tone.

Step 2 Make a call from the local telephone to a configured dial peer and verify that the call attempt is successful.


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 Pick up the telephone and listen to hear the dial tone from the remote PBX.

Step 2 Dial digits so that the remote PBX routes the call.


You can check the validity of your dial peer and voice port configurations by performing the following tasks:

If you have relatively few dial peers configured, enter the show dial-peer voice command to verify that the data configured is correct.

To show the status of the voice ports, enter the show voice port command.

To show the call status for all voice ports, enter the show call active voice [brief] command.

You can check the validity of your VoFR configuration on the DLCI by performing the following task:

To show the VoFR configuration, enter the show frame-relay vofr [interface [dlci [cid]]] command.

Troubleshooting Tips

If you are having trouble connecting a call, you can try to resolve the problem by performing the following tasks:

If no FRF.11 calls are going through, make sure that the frame-relay voice bandwidth command is configured.

If you have Voice over Frame Relay configured on a PVC and are experiencing problems with data connectivity on that PVC, make sure that the frame-relay fragment command has been configured.

If you suspect that the problem is with the dial plan or the dial peers, use the show dial-plan number dial string command to display which dial peers are used when a specific number is called.

If you have problems connecting an FRF.11 trunk call, make sure that the session protocol dial peer command is set to frf11-trunk.

If you are configuring FRF.11 trunk calls, verify that the called-number vofr dial peer command is configured and that its number matches the destination pattern of the corresponding POTS dial peer.

Be sure that the voice port is set to no shutdown.

Be sure that the serial port or the T1/E1 controller is set to no shutdown.

Be sure to toggle the voice port (by first entering shutdown, then no shutdown) every time you enter the connection trunk or no connection trunk commands.

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.

Router A (Cisco 3600)
Router B (FlexWAN or Enhanced FlexWAN on a Cisco 7600)

class-map frf

match protocol vofr

policy-map llq

class frf

priority t

policy-map llq-shape

class class-default

shape average u s

service-policy llq
interface serial 0/0
interface serial 0/0/0.1
encapsulation frame-relay
encapsulation frame-relay
frame-relay traffic shaping

interface serial 0/0.1 point-to-point
interface serial 0/0/0.1 point-to-point
frame-relay interface-dlci 100
frame-relay interface-dlci 100
class frf12-class
class frf12-class
map-class frame-relay frf12-class
map-class frame-relay frf12-class
frame-relay fragment y
frame-relay fragment y
frame-relay cir s
service-policy output llq-shape 
frame-relay bc u


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.

Router A (Cisco 3600)
Router B (FlexWAN or Enhanced FlexWAN on a Cisco 7600)

class-map frf

match protocol vofr



policy-map llq

class frf

priority t



policy-map llq-shape

class class-default

shape average u s

service-policy llq


interface serial 0/0
interface serial 0/0/0.1
encapsulation frame-relay
encapsulation frame-relay
frame-relay traffic shaping



interface serial 0/0.1 point-to-point
interface serial 0/0/0.1 point-to-point
frame-relay interface-dlci 100
frame-relay interface-dlci 100
vofr data 4 call 5
vofr data 4 call 5
class frf11-class
class frf11-class


map-class frame-relay frf11-class
map-class frame-relay frf11-class
frame-relay fragment y
frame-relay fragment y
frame-relay voice-bandwidth t
frame-relay voice-bandwidth t
frame-relay cir s
service-policy llq-shape
frame-relay bc u


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.

Router A (FlexWAN or Enhanced FlexWAN on a Cisco 7600)
Router B (Cisco MC3810)
class-map frf

match protocol vofr



policy-map llq

class frf

priority t



policy-map llq-shape

class class-default

shape average u s

service-policy llq



interface serial 0/0/0.1
interface serial 0
  ip address xxx.xxx.xxx 
    255.255.255.0
  ip address xxx.xxx.xxx 
    255.255.255.0
  encapsulation frame-relay
  encapsulation frame-relay
  frame-relay interface-dlci 100
  frame-relay traffic-shaping
  class voice
  frame-relay interface-dlci 100
  vofr data 4 call-control 5
  class voice

  vofr data 4 call-control 5


map-class frame-relay frf11-class
map-class frame-relay voice
  frame-relay fragment y
  frame relay cir s
  frame-relay voice-bandwidth v
  frame relay bc u
service-policy llq-shape
  frame-relay voice bandwidth v

  frame-relay min-cir x

  frame-relay fragment y


voice-port 2/0/0
voice-port 1/5
  connection trunk 6001 answer-mode
  connection trunk 7001


dial-peer voice 1 pots
dial-peer voice 2 pots
  destination-pattern 7001
  destination-pattern 6001
  port 2/0/0
  port 1/5


dial-peer voice 2 vofr
dial-peer voice 4 vofr
  codec x bytes y 
  codec x bytes y
  destination-pattern 6001
  destination-pattern 7001
  session protocol cisco-switched
  session protocol cisco-switched
  session target Sn 100
  session target Sn 100

FRF.11 Trunk Calls Between Two Routers

This is an example of FRF.11 trunk calls configured between two routers.

Router A (FlexWAN or Enhanced FlexWAN on a Cisco 7600)
Router B (Cisco MC3810)
class-map frf

match protocol vofr



policy-map llq

class frf

priority t



policy-map llq-shape

class class-default

shape average u s

service-policy llq



interface serial 0/0/0.1
interface serial 0
  ip address xxx.xxx.xxx 
    255.255.255.0
  ip address xxx.xxx.xxx 
    255.255.255.0
  encapsulation frame-relay
  encapsulation frame-relay
  frame-relay interface-dlci 100
  frame-relay traffic-shaping
  class voice
  frame-relay interface-dlci 100
  vofr data 4 
  class voice

  vofr data 4


map-class frame-relay frf11-class
  map-class frame-relay voice
  frame-relay fragment y
  frame relay cir s
  frame-relay voice-bandwidth v
  frame-relay min-cir in x
service-policy llq-shape
  frame relay bc u

  frame-relay voice bandwidth v

  frame-relay fragment y


voice-port 2/0/0
voice-port 1/5
  connection trunk 6001
  connection trunk 7001


dial-peer voice 1 pots
dial-peer voice 2 pots
  destination-pattern 7001
  destination-pattern 6001
  port 2/0/0
  port 1/5


dial-peer voice 2 vofr
dial-peer voice 4 vofr
  codec x bytes y bytes
  codec x bytes y
  destination-pattern 6001
  destination-pattern 7001
  session protocol frf11-trunk
  session protocol frf11-trunk
  session target Sn 100 d
  session target Sn 100 d
  called-number 7001
  dtmf-relay
  dtmf-relay
  vad
  vad


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.

Router A (Cisco 3600) Endpoint
Router C (Cisco 3600) Tandem Node
Router B (FlexWAN or Enhanced FlexWAN on a Cisco 7600) Endpoint


class-map frf


match protocol vofr





policy-map llq


class frf


priority t





policy-map llq-shape


class class-default


shape average u s


service-policy llq



interface serial 0/0
interface serial 0/0
interface serial 0/0/0.1
  encapsulation frame-relay
  encapsulation frame-relay
  encapsulation frame-relay
  frame-relay traffic-shaping
  frame-relay traffic-shaping
  frame-relay interface-dlci 100
  frame-relay interface-dlci 100
  frame-relay interface-dlci 100
  class voice
  class voice
  class voice
  vofr data 4 call-control 5
  vofr data 4 call-control 5
  vofr data 4 call-control 5




map-class frame-relay voice
interface serial 0/1
map-class frame-relay voice
  frame-relay cir a
  encapsulation frame-relay
  frame-relay fragment d
  frame-relay min-cir t
  frame-relay traffic-shaping
  frame-relay voice-bandwidth c
  frame-relay bc b
  frame-relay interface-dlci 200
service-policy llq-shape
  frame-relay voice bandwidth c
  class voice

  frame-relay fragment d
  vofr




dial-peer voice 1 pots
map-class frame-relay voice
dial-peer voice 1 pots
  destination-pattern 1001
  frame-relay cir a
  destination-pattern 2001
  port 1/0/0
  frame-relay min-cir t
  port 1/0/0

  frame-relay bc b


  frame-relay voice bandwidth c

dial-peer voice 2 vofr
  frame-relay fragment d
dial-peer voice 2 vofr
  destination-pattern 2...

  destination-pattern 1...
  session target serial 0/0 100
dial-peer voice 1 vofr
  session target serial 0/0 200

  destination-pattern 1...

voice-port 1/0/0
  session target serial 0/0 100
voice-port 1/0/0




dial-peer voice 2 vofr


  destination-pattern 2...


  session target serial 0/1 200


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.

Router A (FlexWAN or Enhanced FlexWAN on a Cisco 7600) Endpoint
Router C (Cisco MC3810) Tandem Node
Router B (FlexWAN or Enhanced FlexWAN on a Cisco 7600) Endpoint
class-map frf

class-map frf
match protocol vofr

match protocol vofr



policy-map llq

policy-map llq
class frf

class frf
priority t

priority t



policy-map llq-shape

policy-map llq-shape
class class-default

class class-default
shape average u s

shape average u s
service-policy llq

service-policy llq



interface serial 0/0/0.1
interface serial 0
interface serial 0/0/0.1
  encapsulation frame-relay
  encapsulation frame-relay
  encapsulation frame-relay
  frame-relay interface-dlci 100
  frame-relay traffic-shaping
  frame-relay interface-dlci 200
  class voice
  frame-relay interface-dlci 100
  class voice
  vofr data 4 call-control 5
  class voice
  vofr data 4 call-control 5

  vofr data 4 call-control 5




map-class frame-relay voice
interface serial 1
map-class frame-relay voice
  frame-relay fragment d
  encapsulation frame-relay
  frame-relay fragment d
  frame-relay voice-bandwidth c
  frame-relay traffic-shaping
  frame-relay voice-bandwidth c
service-policy llq-shape
  frame-relay interface-dlci 200
service-policy llq-shape

  class voice


  vofr data 4 call-control 5




dial-peer voice 1 pots
map-class frame-relay voice
dial-peer voice 1 pots
  destination-pattern 1001
  frame-relay cir a
  destination-pattern 2001
  port 1/0/0
  frame-relay min-cir t
  port 1/0/0

  frame-relay bc b


  frame-relay voice bandwidth c

dial-peer voice 2 vofr
  frame-relay fragment d
dial-peer voice 2 vofr
  destination-pattern 2...

  destination-pattern 1...
  session target serial 0/0/100
dial-peer voice 1 vofr
  session target serial 0/0/200

  destination-pattern 1...

voice-port 1/0/0
  session target serial 0/0 100
voice-port 1/0/0




dial-peer voice 2 vofr


  destination-pattern 2...


  session target serial 0/1 200


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.

Router A (Cisco 2600) Endpoint
Router C (FlexWAN or Enhanced FlexWAN on a Cisco 7600) Tandem Node
Router B (Cisco MC3810) Endpoint

class-map frf


match protocol vofr





policy-map llq


class frf


priority t





policy-map llq-shape


class class-default


shape average u s


service-policy llq




interface serial 0/0
interface serial 0/0/0.1
interface serial 0
  encapsulation frame-relay
  encapsulation frame-relay
  encapsulation frame-relay
  frame-relay traffic-shaping
  frame-relay interface-dlci 100
  frame-relay traffic-shaping
  frame-relay interface-dlci 100
  class voice
  frame-relay interface-dlci 200
  class voice
  vofr data 4 call-control 5
  class voice
  vofr data 4 call-control 5

  vofr data 4 call-control 5



map-class frame-relay voice
interface serial 0/1/0.1
map-class frame-relay voice
  frame-relay cir a
  encapsulation frame-relay
  frame-relay cir a
  frame-relay min-cir t
  frame-relay interface-dlci 200
  frame-relay min-cir t
  frame-relay bc b
  class voice
  frame-relay bc b
  frame-relay voice bandwidth c
  vofr data 4 call-control 5
  frame-relay voice bandwidth c
  frame-relay fragment d

  frame-relay fragment d



dial-peer voice 1 pots
map-class frame-relay voice
dial-peer voice 1 pots
  destination-pattern 1001A
  frame-relay fragment d
  destination-pattern 2001A
  port 1/0/0
  frame-relay voice-bandwidth c
  port 1/1

service-policy llq-shape




dial-peer voice 2 vofr
dial-peer voice 1 vofr
dial-peer voice 2 vofr
  destination-pattern 2...
  destination-pattern 1...
  destination-pattern 1...
  session target serial 0/0 100
  session target serial 0/0/0.1 100
  session target serial 0 200



voice-port 1/0/0
dial-peer voice 2 vofr
voice-port 1/1
  connection trunk 2001A 
    answer-mode
  destination-pattern 2...
  connection trunk 1001A

  session target serial 0/1/0.1 200


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.

Router A (FlexWAN or Enhanced FlexWAN on a Cisco 7600 router)
Router B (FlexWAN or Enhanced FlexWAN on a Cisco 7600 router)
class-map frf
class-map frf
match protocol vofr
match protocol vofr


policy-map llq
policy-map llq
class frf
class frf
priority t
priority t


policy-map llq-shape
policy-map llq-shape
class class-default
class class-default
shape average u s
shape average u s
service-policy llq
service-policy llq


interface serial 0/0/0.1
interface serial 0/0/0.1
  encapsulation frame-relay
  encapsulation frame-relay
  frame-relay interface-dlci 100
  frame-relay interface-dlci 100
  class voice
  class voice
  vofr data 4 call-control 5
  vofr data 4 call-control 5


interface serial 1/0/0.1
interface serial 1/0/0.1
  encapsulation frame-relay
  encapsulation frame-relay
  frame-relay interface-dlci 200
  frame-relay interface-dlci 200
  class voice
  class voice
  vofr data 4 call-control 5
  vofr data 4 call-control 5


map-class frame-relay voice
map-class frame-relay voice
  frame-relay fragment d
  frame-relay fragment d
  frame-relay voice-bandwidth c
  frame-relay voice-bandwidth c
  service-policy llq-shape
  service-policy llq-shape


dial-peer voice 1 pots
dial-peer voice 1 pots
  destination-pattern 1001A
  destination-pattern 2001A
  port 1/1/0
  port 1/1/0


dial-peer voice 100 vofr
dial-peer voice 100 vofr
  destination-pattern 2...
  destination-pattern 1...
  session target serial0 100
  session target serial0 100
  preference 1
  preference 1


dial-peer voice 200 vofr
dial-peer voice 200 vofr
  destination-pattern 2...
  destination-pattern 1...
  session target serial1 200
  session target serial1 200
  preference 2
  preference 2


voice-port 1/1/0
voice-port 1/1/0
  connection trunk 2005A
  description FXS port
  description FXO port
  connection trunk 1001A answer-mode

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 DSCP-based classification is not supported on the FlexWAN or Enhanced FlexWAN modules with the Frame Relay PVC Bundles feature.



Note Frame Relay PVC Bundles are not supported for IPv6.


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 RFC 1483 has been updated and superseded by RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5.


RBE Restrictions and Usage Guidelines

Routed Bridged Encapsulation (RBE) has the following restrictions and limitations:

On a Cisco 7600 router with a Supervisor Engine 720 (Sup720) or Route Switch Processor 720 (RSP720) and Enhanced FlexWAN module, an ATM port adapter or shared port adapter (SPA) with an RBE configuration can send packets to only a single MAC address. See the following section ("RBE Configuration Limitation Supports Only One Remote MAC Address") for details.

Supports only AAL5SNAP encapsulation.

Cisco IOS Release 12.2SR and later releases support MPLS over RBE and MPLS-VPN over RBE on the Enhanced FlexWAN. See the "MPLS Over RBE" section on page 2-9 for more information.

Open Shortest Path First (OSPF) over RBE has special configuration requirements to consider. See the "OSPF over RBE Configuration Requirements" section for more information.

Supports only IP access lists, not MAC-layer access lists.

Supports only PVCs on point-to-point subinterfaces. SVCs are not supported for RBE bridging.

The bridge-domain command cannot be used on any PVC that is configured for RBE because an RBE PVC acts as the termination point for bridged packets.

The IS-IS protocol is not supported on point-to-point PVCs that are configured for RBE bridging.

RBE does not support dot1q-tagged (bridge-domain 100 dot1q) packets.

Supports IPv4 only—not IPv6.

DHCP relay agent information (DHCP Option 82) for RBE is not supported on Cisco 7600 series routers.

show ip cache verbose command does not work with the RBE feature; however, you can use the show arp command to achieve the same functionality.

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:

ATM PA-A3 and ATM PA-A6 port adapters on the FlexWAN and Enhanced FlexWAN modules

ATM SPAs on the Cisco 7600 SIP-200

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. Use the bridge domain vlan-id command to configure the ATM PVC for RFC 1483 bridging.

2. Use the interface vlan vlan-id command to configure a VLAN interface and then move the IP address of the RBE subinterface under the VLAN address.

Supervisor Engine and Line Card Support for RBE

The following Cisco 7600 Supervisor Engines support RBE:

Route Switch Processor 720

Supervisor Engine 720

Supervisor Engine 32

Supervisor Engine 2 (not supported in Cisco IOS Release 12.2SR and later releases)

The following Cisco 7600 line cards and SIPs support RBE:

FlexWAN (not supported in Cisco IOS Release 12.2SR and later releases)

Enhanced FlexWAN

Cisco 7600 SIP-200

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:

PA-A6-OC3MM

PA-A6-OC3SMI

PA-A6-OC3SML

PA-A6-T3

PA-A6-E3

PA-A3-OC3MM

PA-A3-OC3SMI

PA-A3-OC3SML

PA-A3-T3

PA-A3-E3

RBE is also supported on these SPAs (which are only available on the Cisco 7600 SIP-200 and Cisco 7600 SIP-400):

SPA-2XOC3-ATM

SPA-4XOC3-ATM


Note Serial port adapters are not supported with RBE on the Enhanced FlexWAN or FlexWAN module.


RBE Configuration Procedure

To configure ATM Routed Bridged Encapsulation, use the following commands:

 
Command or Action
Purpose

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 You can enter the atm route-bridge ip command either before or after you create the PVC.

 

Note The atm route-bridge ip command, like other subinterface configuration commands, is not automatically removed when you delete a subinterface. If you want to remove a subinterface and re-create it without RBE, be sure to use the no atm route-bridge ip command to manually remove the RBE configuration.

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 The IP address should be on the same subnet as the remote bridged network (the Ethernet network).

 

Note (Optional) If you plan to run OSPF over the interface, see the "OSPF over RBE Configuration Requirements" section section for information about things to consider.

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.

name—(Optional) An arbitrary string that identifies this PVC.

vpi—Specifies the VPI ID. The valid range is 0 to 255.

vci—Specifies the VCI ID. The valid range is 1 to 65535. Values 1 to 31 are reserved and should not be used, except for 5 for the QSAAL PVC and 16 for the ILMI PVC.

 

Note With the pvc command, the vpi/vci combination forms a unique identifier for the interface and all of its subinterfaces. If you specify a vpi/vci combination that was used on another subinterface, the software assumes that you want to modify that PVC's configuration and automatically switches to its parent subinterface.

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.

show arp

show adjacency detail

show mls cef

Following is an example of command output for the show arp command:

Router# show arp 

Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  122.0.0.1               6   00d0.04f7.5c00  ARPA   ATM2/0/0.2


Following is an example of the command output for the show adjacency detail command:

Router# show adjacency detail 

Protocol Interface                 Address
IP       EOBC0/0                   127.0.0.51(4)
                                   0 packets, 0 bytes
                                   epoch 0
                                   sourced in sev-epoch 538
                                   Encap length 14
                                   0000150000000000150000000800
                                   ARP
IP       POS7/1/0                  point2point(10)
                                   1000 packets, 104000 bytes
                                   epoch 0
                                   sourced in sev-epoch 538
                                   Encap length 4
                                   0F000800
                                   P2P-ADJ
TAG      POS7/1/0                  point2point(4)
                                   0 packets, 0 bytes
                                   epoch 0
                                   sourced in sev-epoch 538
                                   Encap length 4
                                   0F008847
                                   P2P-ADJ
IP       ATM2/0/0.2                122.0.0.1(14)
                                   1000 packets, 108000 bytes
                                   epoch 0
                                   sourced in sev-epoch 538
                                   Encap length 28
                                   00010000AAAA030080C20007000000D0
                                   04F75C0000D004B86C000800
                                   ARP
TAG      ATM2/0/0.2                122.0.0.1(3)
                                   0 packets, 0 bytes
                                   epoch 0
                                   sourced in sev-epoch 538
                                   Encap length 28
                                   00010000AAAA030080C20007000000D0
                                   04F75C0000D004B86C008847
                                   P2P-ADJ 

OSPF 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:

Both ends of the Open Shortest Path First (OSPF) link must belong to the same type of network (point-to-point or broadcast). Use the ip ospf network {point-to-point | broadcast} command to specify the network type.

Both ends of the OSPF link must use the same maximum transmission unit (MTU) size or they must ignore MTU size altogether. Otherwise, OSPF detects a mismatch between the interfaces and it never becomes active. For example, the default Ethernet MTU size is 1500 bytes and the default ATM MTU size is 4470 bytes. To run OSPF on Ethernet-based customer premises equipment (CPE) that is connected to an RBE (ATM) interface, you must either set both interfaces to the same MTU size or turn off MTU checking on both interfaces.

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:

http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfospf.html

http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfospf.html

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.1
  encapsulation dot1Q 100
  ip address 20.0.0.1 255.0.0.0
  ip ospf network point-to-point
  ip ospf mtu-ignore

RBE (ATM) Interface Configuration

interface atm3/0/0.2 point 
  ip address 20.0.0.2 255.0.0.0
  ip ospf network point-to-point
  ip ospf mtu-ignore
  atm route-bridge ip 
  pvc 10/100

Configuring 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 Cisco IOS Release 12.2SR introduces support for BCP on Multilink PPP (MLPPP). This feature is available on serial interfaces that are part of a multilink bundle. For more information, see the "Configuring BCP over MLPPP (Trunk Mode Only)" section.


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)

PA-H

PA-2H

Packet over Sonet (OC-3)

PA-POS-OC3MM

PA-POS-OC3SMI

PA-POS-OC3SML

PA-POS-2OC3

T1/E1

PA-4T+

PA-8T-V35

PA-8T-X21

PA-8T-232

PA-MC-2E1/120

PA-MC-2T1

PA-MC-4T1

PA-MC-8T1

PA-MC-8E1/120

PA-MC-8TE1+

PA-MC-STM-1

PA-4E1G-120

PA-4E1G-75

T3/E3 (clear-channel and channelized)

PA-T3

PA-2T3

PA-T3+

PA-2T3+

PA-E3

PA-2E3

PA-MC-T3

PA-MC-2T3+

PA-MC-E3


Note Although RFC 3518 supports both tagged and untagged frames, presently BCP on the FlexWAN and Enhanced FlexWAN modules supports only tagged frames. This means that every Ethernet frame sent across a BCP link has the two-byte 802.1Q header. All normal traffic on a VLAN is tagged; however, traffic on the native VLAN is not. To enable native VLAN tagging, you must issue the vlan dot1q tag native command on the native VLAN. Be sure to enable or disable native VLAN tagging on all of the switches in your network. If you do not, all traffic will be dropped.



Note Although RFC 3518 specifies support for Token Ring and Fiber Distributed Data Interface (FDDI), BCP on the FlexWAN and Enhanced FLexWAN modules supports only Ethernet currently.


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 (switchport)

Single-VLAN BCP (bridge-domain)

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:

There are some differences between the Ethernet trunk ports and BCP trunk ports.

Ethernet trunk ports support ISL and 802.1Q encapsulation, but BCP trunk ports support only 802.1Q.

Ethernet trunk ports support native VLAN (untagged), but BCP trunk ports do not.

Ethernet trunk ports support Dynamic Trunk Protocol (DTP), which is used to automatically determine the trunking status of the link. BCP trunk ports are always in trunk state and no DTP negotiation is performed.

The default behavior of Ethernet trunk ports is to allow all VLANs on the trunk. The default behavior of BCP trunks is to disallow all VLANs. This means that VLANs that need to be allowed have to be explicitly configured on the BCP trunk port.

Use the switchport command under the WAN interface when configuring trunk mode BCP.

For trunk mode BCP, you can configure a maximum of 60 switchports per bay in a FlexWAN or Enhanced FlexWAN module.

With Cisco IOS Release 12.2SR and later, you can configure BCP trunk mode on channelized interfaces. With earlier releases, you could not.

To use VLANs in trunk mode BCP, you must use the vlan command to manually add the VLANs to the VLAN database.

For trunk mode BCP (switchport), STP interoperability is the same as Ethernet switchports. This means that the STP path cost of WAN links can be changed and other STP functionality like BPDU Guard and PortFast will work on the WAN links. However, we recommend that you do not change the default values.

VLAN Trunking Protocol (VTP) is supported.


Note The management VLAN (VLAN 1) must be explicitly enabled on the trunk to send VTP advertisements.


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:

 
Command
Purpose

Step 1 

Router(config)# interface interface-type slot/bay/port

Selects the interface.

Step 2 

Router(config-if)# switchport

Puts an interface that is in Layer 3 mode into Layer 2 mode for Layer 2 configuration.

Note When you issue the switchport command, encapsulation is automaticlly set to PPP.

Note Other commands (see example below) are nvgened at this point. You cannot change these options.

Step 3 

Router(config-if)# shutdown

Shuts down an interface.

Note This command is mandatory to invoke BCP.

Step 4 

Router(config-if)# no shutdown

Reopens an interface.

Note This command is mandatory to invoke BCP.

Step 5 

Router(config-if)# switchport trunk allowed vlan vlan-list

By default, no VLANs are allowed. Use this command to explicitly allow VLANs; valid values for vlan-list are from 1 to 4094.

The following example shows a trunk mode BCP configuration on a POS interface:

Router(config)# interface p4/1/0 
Router(config-if)# switchport 

Configuring switchport changes encapsulation to PPP automatically.

%Please shut/no shut POS4/1/0 to bring up BCP
Router(config-if)# shutdown 
Router(config-if)# no shutdown 
Router(config-if)# switchport trunk allowed vlan all 

%Internal vlans not available for bridging:1006-1018,1021   

Router(config-if)# ^Z
Router#
Router# show run interface p4/1/0 
Building configuration...

Current configuration : 191 bytes
!
interface POS4/1/0
switchport
switchport trunk allowed vlan all
switchport mode trunk  

The above is nvgened automatically after switchport is entered.

switchport nonegotiate 

The above is nvgened automatically after switchport is entered.

no ip address
encapsulation ppp
clock source internal
end

Configuring 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.

The feature is available in Cisco IOS 12.2SR and later releases, and is only available for the Enhanced FlexWAN module (since the FlexWAN module is not supported in these releases).

The BCP feature is available with distributed MLPPP only, and all of the restrictions that apply to distributed MLPPP also apply to BCP over MLPPP. See the "Configuring Distributed Multilink Point-to-Point Protocol" section for a list of those restrictions.

Only channelized interfaces are supported. See Table 3-1 for a list of supported port adapters.

This feature is supported in BCP trunk mode only.

You can configure bridging on the MLPPP bundle only. You cannot configure bridging on the member links in the MLPPP bundle.

To configure BCP over MLPPP, perform these steps:

 
Command
Purpose

Step 1 

Router(config)# interface multilink group-number

Enters multilink interface configuration mode and creates a multilink bundle (where group-number is a non-zero number used to identify the bundle).

The multilink bundle is assigned the name Multilinkx (where x is the same as group-number). For example, interface multilink 2 creates a bundle named Multilink2.

Step 2 

Router(config-if)# switchport

Configures the multilink bundle for switching (Layer 2) mode and enters Layer 2 configuration mode.

Note When you issue the switchport command, PPP encapsulation is automatically set on the multilink bundle.

Step 3 

Router(config-if)# switchport trunk allowed vlan vlan-list

By default, no VLANs are allowed on BCP trunks. Use this command to explicitly allow the VLANs specified by vlan-list (valid values are from 1 to 4094).

Step 4 

Router(config-if)# switchport mode trunk

Selects trunking mode for the multilink bundle.

Step 5 

Router(config-if)# switchport nonegotiate

Turns off Dynamic Trunk Protocol (DTP) negotiation, which is not necessary in BCP trunk mode.

Step 6 

Router(config-if)# no ip address

Specifies that no IP address be assigned to the bundle.

Step 7 

Router(config-if)# ppp multilink

Enables Multilink PPP on the bundle.

Step 8 

Router(config-if)# shutdown

Router(config-if)# no shutdown

Shuts down the multilink bundle interface and restarts the interface. Note that you must issue both commands to activate the multilink bundle.

Step 9 

Router(config-if)# exit

Exits multilink interface configuration mode.

Step 10 

Configure the interfaces for the links that will be part of the multilink bundle and add them to the bundle. To do this, enter interface configuration mode for each interface and perform Steps 11 and 12.

Step 11 

Router(config-if)# no ip address
Router(config-if)# encapsulation ppp
Router(config-if)# ppp multilink

For each interface that is part of the multilink bundle, enter interface configuration mode and issue these commands to enable PPP encapsulation and PPP multilink, and to specify that no IP address be used.

Step 12 

Router(config-if)# multilink-group group-number

Adds the interface to the multilink bundle identified by group-number (this is the same value used in the interface multilink group-number command).


Note To remove a member link from an MLPPP bundle that is configured for BCP, you must issue the no ppp multilink command before you issue the no multilink-group command.


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 1 
Router(config-if)# switchport 
Router(config-if)# switchport trunk allowed vlan 100 
Router(config-if)# switchport mode trunk 
Router(config-if)# switchport nonegotiate 
Router(config-if)# no ip address 
Router(config-if)# ppp multilink 
Router(config-if)# shutdown 
Router(config-if)# no shutdown 
Router(config-if)# exit 

The 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:0 
Router(config-if)# no ip address 
Router(config-if)# encapsulation ppp 
Router(config-if)# ppp multilink 
Router(config-if)# multilink-group 1 
!
Router(config)# interface Serial1/0/0.1/1/1/2:0 
Router(config-if)# no ip address 
Router(config-if)# encapsulation ppp 
Router(config-if)# ppp multilink 
Router(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:0 
Router(config-if)# no ppp multilink 
Router(config-if)# no multilink-group 1 

Verifying 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.

 
Command
Purpose
 

Router# show interfaces [interface interface-number] trunk [module number]

Displays the interface-trunk information.

 

Router# show interfaces [interface interface-number] switchport [module number]

Displays the administrative and operational status of a switching (nonrouting) port.

 

Router# show interfaces [{interface interface-number}]

Displays traffic that is seen by a specific interface.

The following are examples of trunk mode BCP verification:

Router# show interfaces trunk 

Port          Mode         Encapsulation  Status        Native vlan
PO4/1/0       on           802.1q         trunking      1

Port          Vlans allowed on trunk
PO4/1/0       1-1005,1025-1026,1028-4094

Port          Vlans allowed and active in management domain
PO4/1/0       1,100,200

Port          Vlans in spanning tree forwarding state and not pruned
PO4/1/0       1,100,200

Router# show interfaces switchport 

Name: PO4/1/0
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: down
Administrative Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: none
Administrative private-vlan host-association: none 
Administrative private-vlan mapping: none 
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: 100
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Unknown unicast blocked: disabled
Unknown multicast blocked: disabled

Router# show interface p4/1/0 
POS4/1/0 is up, line protocol is up 
  Hardware is Packet over Sonet
  MTU 4470 bytes, BW 155000 Kbit, DLY 100 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, crc 16, loopback not set
  Keepalive set (10 sec)
  Scramble disabled
  LCP Open
  Open: BRIDGECP, CDPCP
  Last input 00:00:05, output 00:00:05, output hang never
  Last clearing of "show interface" counters 18:48:09
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 1000 bits/sec, 1 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     13161719 packets input, 1145463122 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicast)
     0 runts, 0 giants, 0 throttles
              0 parity
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     1685 packets output, 620530 bytes, 0 underruns
     0 output errors, 0 applique, 30 interface resets
     0 output buffer failures, 0 output buffers swapped out
     11 carrier transitions
Router1#

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:

Use the bridge-domain vlan dot1q command under the WAN interface. The dot1q keyword is necessary. It indicates that all frames on the BCP link will be tagged with a 802.1Q header. Untagged frames received on a BCP link will be dropped.

The encapsulation of the interface must be PPP; otherwise, the bridge-domain command will not be accepted.

For single-VLAN BCP, a maximum of 60 ports can be configured per VLAN per chassis.

VLANs must be manually added to the VLAN database, using the vlan command, to be able to use those VLANs in single-VLAN BCP.

For Single-VLAN BCP, only basic STP interoperability is supported. This means that single-VLAN BCP interfaces will participate in the STP domain and the correct path cost of the links will be calculated; however, changing any STP parameters for the link is not supported.

VTP is not supported on single-VLAN BCP.

Configuring Single-VLAN BCP

To configure single-VLAN BCP, perform these tasks:

 
Command
Purpose

Step 1 

Router(config)# interface interface-type slot/bay/port

Selects the interface.

Step 2 

Router(config-if)# no ip address

Disables IP processing on a particular interface by removing its IP address.

Step 3 

Router(config-if)# encapsulation ppp

Configures the interface for PPP encapsulation.

Step 4 

Router(config-if)# bridge-domain vlan dot1q

Establishes a domain and tags all Ethernet frames on the BCP link with the 802.1Q header.

Step 5 

Router(config-if)# shutdown

Shuts down an interface.

Note This command is mandatory to invoke BCP.

Step 6 

Router(config-if)# no shutdown

Reopens an interface.

Note This command is mandatory to invoke BCP.

The following example shows a single-VLAN BCP configuration:

Router# show run interface p4/1/0
Building configuration...

Current configuration : 78 bytes
!
interface POS4/1/0
 no ip address 

For BCP ports, the recommendation is not to configure the IP address.

no keepalive
 clock source internal
end

Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# interface p4/1/0
Router(config-if)# bridge-domain 100 dot1q
Must set encapsulation to PPP before using hw bridging over PPP 

Unlike switchport, encapsulation is not changed to PPP when bridge-domain is entered.

Router(config-if)# exit
Router(config)# exit
Router(# sho