FlexWAN and Enhanced FlexWAN Modules Installation and Configuration Guide - FlexWAN and Enhanced FlexWAN Software Features Configuration Information [Cisco 7600 Series Routers]

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 Private Hosts Switched Virtual Interface (VLAN and VPLS)

Port classification

Requirements and Restrictions

Verifying the Private Hosts SVI configuration

Sample Configuration For Private Hosts VPLS Configuration

Sample Configuration For Private Hosts Interface VLAN 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).

Note Effective from Cisco IOS Software Release 15.0(1)S, a number of QoS commands documented in this chapter are hidden in the software image; hence you have to use their replacement commands. Although the hidden commands are still available on Cisco IOS Software, you cannot access these commands from the CLI Interactive Help. For more information on the replacement commands, see the Legacy QoS Command Deprecation feature document at:
http://www.cisco.com/en/US/docs/ios/ios_xe/qos/configuration/guide/legacy_qos_cli_deprecation_xe.html

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 Private Hosts Switched Virtual Interface (VLAN and VPLS)

•Configuring Half-Bridging

•Configuring Distributed Network-Based Application Recognition

•Configuring Distributed Network-Based Application Recognition

•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 Private Hosts Switched Virtual Interface (VLAN and VPLS)

The Private Hosts feature allows automatic insertion of Router Switched Virtual Interface (SVI) MAC into the private host configuration. Private hosts track the L2 port that a server is connected to, and limits undesired traffic through MAC-layer access control lists (ACLs). Hosts can carry multiple traffic types via trunk ports, remain isolated from each other, and still communicate to a common server. Private hosts work at the Layer 2 interface level.

From 12.2(33)SRD4 onwards, this feature redirects broadcast and unicast traffic from isolated ports over VPLS Virtual Circuit. You can add a VPLS enabled VLAN ( cross-connect configured in a VLAN) in the Private Host VLAN-list along with regular VLAN and SVI.

Private Host limits VPLS support for only one VLAN. You cannot add another VPLAS VLAN if a VPLS VLAN exists in the Private Host VLAN-list. Similary , if any VLAN in the Vlan-list has cross-connect configured, you cannot configure another cross-connect on another VLAN in the VLAN-list.

Port classification

The various types of ports are:

–Isolated ports: The hosts that need to be isolated are directly or indirectly connected through DSLAMs to this type of port. The unicast traffic received on these ports should always be destined toward specified upstream devices.

–Promiscuous ports: The ports facing the core network or devices such as BRAS and multicast servers are called promiscuous ports. These ports can allow any unicast or broadcast traffic received from upstream devices.

Private host traffic is treated as Layer 2 traffic and routing needs an external router to be configured. Instead of configuring a server MAC address into a private host, you must configure the router MAC address. This feature adds the SVIs into the private host configuration, eliminating the need for the external router. For more information on the Private Hosts feature, see the Cisco 7600 Series Cisco IOS Software Configuration Guide, 12.2SR at http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/pacl.html

Requirements and Restrictions

When you configure the Private Hosts SVI feature, follow these requirements and restrictions:

•Many VLANs can be associated with the Private Hosts feature.

•However, only one of those VLANs can have cross-connect configured for a private host with VPLS.

•Other VLANs in the router can have cross-connect, but they cannot be associated the with Private Hosts feature.

•Private Host limits VPLS support for only one VLAN. If the Private Host VLAN-list already has a VPLS VLAN (VLAN with cross-connect), addition of another VPLS VLAN is blocked. Similary, if cross-connect is configured in any VLAN in the VLAN-list, you cannot configure cross-connect on another VLAN in the VLAN-list.

•You cannot restrict private host SVIs to a configured subset of VLANs. If you want a subset of VLANs to use SVIs, you must ensure that all SVIs on the VLANs can be routed.

•This feature is not supported on hybrid systems.

•This feature installs protocol- independent PACLs and enables MAC classification on the VLAN. As a result, features such as RACLs do not work with it.

•This feature is supported only on PFC-3BXL or cards higher than the PFC-3BXL configuration.

•This feature is not supported on EARL6 or below.

To configure the Private Hosts SVI feature, perform the following steps in the global configuration mode:
Command

Purpose
Step 1
Router(config)# [no] private-hosts
Enables or disables the Private Hosts SVI feature on a Cisco 7600 device globally. The no form of the command disables this feature globally. This command is in disabled mode by default .
Step 2

Router(config)# [no] private-hosts layer3

(Optional) Enables Layer 3 routing on private hosts on a Cisco 7600 device globally. Use the no form of the command to disable Layer 3 routing.
Step 3
Router(config)# [no] private-hosts mac-list mac-list-name mac-address
(Optional) Populates the MAC a ddress list. The no form of the command deletes the MAC address from the list. The list itself is deleted after the deletion of last MAC address.
Step 4
Router(config)# [no] private-hosts vlan-list vlan-id
(Optional) Provides a list of VLANs to be isolated. The no form of the command removes the specified VLANs from the isolated VLAN list.

Note The VLAN- list also programs the promiscuous devices' MAC addresses.
Step 5
Router(config)# [no] private-hosts promiscous mac-list-name [vlan-list vlan ids]
(Optional) Provides a list of promiscuous MAC addresses and optional VLAN-list on which these devices might exist.

If the VLAN-list is not specified, the list is taken from the global isolated VLAN list configured. This command can be executed multiple times with different combinations of MAC lists and VLAN lists.
Verifying the Private Hosts SVI configuration

Use the following show commands to verify the Private Hosts SVI (Interface VLAN) configuration:
Command

Purpose
Router# show private-hosts configuration
Displays the global private host configuration.
Router# show private-hosts access-lists
Displays the access lists related to the private hosts.
Router# show private-hosts interface configuration
Displays the ports on which the feature is enabled with the configured mode.
Router# show private-hosts mac-list
Displays the configured MAC lists and their members.
Router-sp# show private-hosts vlans

Displays the VPLS-enabled VLANs related to the private hosts.

Router-sp# show private-hosts index

Displays the redirect index of the private hosts.
Sample Configuration For Private Hosts VPLS Configuration

The following example shows the Private Hosts VPLS configuration:

Router(config)# pseudowire-class mpls

Router(config-pw-class)# encapsulation mpls

Router(config)# l2 vfi 200 manual

Router(config-vfi)# vpn id 200

Router(config-vfi)# neighbor 2.2.2.2 pw-class mpls

Router(config)# private-hosts vlan-list 200-202,204-205

Router(config)# private-hosts promiscuous maclist-1

Router(config)# private-hosts promiscuous maclist-2

Router(config)# private-hosts mac-list maclist-1 0000.1111.9991

Router(config)# private-hosts mac-list maclist-2 0000.1111.9992

Router(config)# private-hosts layer3

Router(config)# private-hosts

Router(config)# int vlan 200

Router(config-if)# no shutdown

Router(config-if)# xconnect vfi 200

! Router(config-if)# interface GigabitEthernet3/2

Router(config-if)# switchport

Router(config-if)# switchport trunk encapsulation dot1q

Router(config-if)# switchport trunk allowed vlan 200-205

Router(config-if)# switchport mode trunk

Router(config-if)# private-hosts mode isolated

PE17_C7606# show private-hosts ?

access-lists Show the private hosts related access lists

configuration Show private hosts global configuration

interface Show private hosts interface related configuration

mac-list Show the mac lists and their members

PE17_C7606# show private-hosts configuration

Private hosts enabled. BR INDEX 1

Layer-3 switching on Private Hosts is enabled

All mandatory configurations configured

Privated hosts vlans lists:

100

Privated promiscuous MAC configuration:

A '*' mark behind the mac list indicates non-existant mac-list

--------------------------------------------------------------------------------

MAC-list VLAN list

--------------------------------------------------------------------------------

server_list *** Uses the isolated vlans ***

--------------------------------------------------------------------------------

VLAN intf MAC addr VLAN list

--------------------------------------------------------------------------------

PE17_C7606#

Sample Configuration For Private Hosts Interface VLAN Configuration

The following example shows a typical configuration of the Private Hosts SVI (Interface VLAN) feature:

Router(config)# private-hosts vlan-list 200-202,204-205

Router(config)# private-hosts promiscuous maclist-1

Router(config)# private-hosts promiscuous maclist-2

Router(config)# private-hosts mac-list maclist-1 0000.1111.9991

Router(config)# private-hosts mac-list maclist-2 0000.1111.9992

Router(config)# private-hosts layer3

Router(config)# private-hosts

!Router(config)# interface GigabitEthernet3/1

Router(config-if)#switchport

Router(config-if)# switchport access vlan 201

Router(config-if)# switchport mode access

Router(config-if)# private-hosts mode promiscuous

Router(config-if)# interface GigabitEthernet3/2

Router(config-if)# switchport

Router(config-if)# switchport trunk encapsulation dot1q

Router(config-if)# switchport trunk allowed vlan 200-205

Router(config-if)# switchport mode trunk

Configuring Half-Bridging

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.

Note NBAR feature is not supported in Release 15.0(1)S and later Releases.

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)

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

Re-enables 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 4-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:

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:
Router# interface multilink1
Router# ip address 10.0.0.0 10.255.255.255
Router# ppp chap hostname group 1
Router# ppp multilink
Router# 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 4-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 4-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 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 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 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 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 6
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 7
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.¹

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

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 ABR² 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.

¹To determine the correct form of the interface atm command, consult your ATM network module, port adapter, or router documentation.

²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

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

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

•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

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]]¹

FRF.11 Annex C

session protocol cisco-switched²

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 cisco³

Cisco proprietary⁴

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]⁵

FRF.11 Annex C

session protocol frf11-trunk

connection trunk destination-string [answer mode]

¹The recommended use of this command is vofr data 4 call-control 5.

²The session protocol cisco-switched option is the default setting. If you do not enter this command, the setting still applies.

³This command consumes data CID 4 and call-control CID 5.

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

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

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:

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

•cept—Use 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-8 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-8.

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

Step 1

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

Displays the interface-trunk information.

Step 2

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

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

Step 3

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(# show run interface p4/1/0
Building configuration...
Current configuration : 78 bytes
!
interface POS4/1/0
 no ip address
 clock source internal
end
Router(config)# interface p4/1/0
Router(config-if)# encapsulation ppp
Router(config-if)# bridge-domain 100 dot1q
%Please shut/no shut POS4/1/0 to bring up BCP
Router(config-if)# shutdown
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# exit
Router#
Router#
Router# show run interface p4/1/0
Building configuration...
Current configuration : 122 bytes
!
interface POS4/1/0
 no ip address
 encapsulation ppp
 bridge-domain 100 dot1q
 clock source internal
end
Verifying Single-VLAN BCP

Because the PPP link has to flap (be brought down and renegotiated), you must enter the show command after you configure single-VLAN BCP.

Command

Purpose

Step 1

Router# show interfaces [interface interface-number]

Displays traffic that is seen by a specific interface.

The following shows an example of verifying single-VLAN BCP:
Router# show interfaces 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:09, output 00:00:09, output hang never
  Last clearing of "show interface" counters 00:00:24
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1
  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
     32 packets input, 1709 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
     17 packets output, 1764 bytes, 0 underruns
     0 output errors, 0 applique, 3 interface resets
     0 output buffer failures, 0 output buffers swapped out
     1 carrier transitions
Router# 
Dot1q Tunneling

The 802.1q tunneling feature allows the creation of secure virtual private networks (VPNs) by using the IEEE 802.1q protocol on Cisco 7600 Series routers or Catalyst 6500 Series switches. This feature allows service providers to segregate traffic from different customers in their infrastructure while significantly reducing the number of virtual LANs (VLANs) required to support VPNs.

Multiple customer VLANs can be carried inside a single VLAN on the Cisco 7600 Series router or Catalyst 6500 switch without losing their unique VLAN ids. The number of VLANs required to support the dot1q tunnels in the service provider network can be reduced significantly.

The VPNs deliver enterprise-scale connectivity deployed on a shared infrastructure with the same security, prioritization, reliability, and manageability enjoyed in a private network. This application note provides an overview of dot1q tunneling and its applicability in networks, especially service providers' networks. The document also includes a brief configuration guide and examples for dot1q tunneling.

Usage Guidelines and Restrictions

When configuring dot1q tunneling, observe the following guidelines and restrictions:

•The l2protocol-tunnel command is not required for BCP tunnel ports; all protocols are tunneled implicitly.

•Because native VLAN is not supported on BCP, VLAN1 STP packets will not be tunneled.

•Use the bridge-domain vlan dot1q-tunnel command under the WAN interface to configure tunneling.

Configuring Dot1q Tunneling

To configure dot1q tunneling, perform these steps:

Command

Purpose

Step 1

Router(config)# interface pos mod/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-tunnel

Configures a VLAN as a tunneled VLAN and the port as a dot1q tunneled port.

Step 5

Router(config-if)# shutdown

Shuts down an interface.

Step 6

Router(config-if)# no shutdown

Reopens an interface.

This example shows a dot1q tunneling 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.
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-tunnel
Must set encapsulation to PPP before using hw bridging over PPP
Router(config-if)# exit
Router(config)#
Router(config)# interface p4/1/0
Router(config-if)# encapsulation ppp
Router(config-if)# bridge-domain 100 dot1q-tunnel 
%Please shut/no shut POS4/1/0 to bring up BCP
Router(config-if)# shutdown
Router(config-if)# no shutdown
Router(config-if)#^Z
Router#
Router#
Router# show run interface p4/1/0
Building configuration...
Current configuration : 129 bytes
!
interface POS4/1/0
 no ip address
 encapsulation ppp
 bridge-domain 100 dot1q-tunnel
 clock source internal
end
The following shows an example of verifying protocol tunneling:
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:04, output 00:00:06, output hang never
  Last clearing of "show interface" counters 00:00:51
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1
  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
     34 packets input, 2282 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
     16 packets output, 2102 bytes, 0 underruns
     0 output errors, 0 applique, 3 interface resets
     0 output buffer failures, 0 output buffers swapped out
     1 carrier transitions
Router#
You can also use the show l2protocol-tunnel command to verify protocol tunneling. The example below shows the output for a Layer 2 Ethernet interface and a POS BCP interface.
Router# show l2protocol-tunnel
COS for Encapsulated Packets: 5
Drop Threshold for Encapsulated Packets: 0
Protocol Drop Counter
-------- -------------
 cdp                 0
 stp                 0
 vtp                 0
Port    Protocol Shutdown  Drop      Encapsulation Decapsulation Drop
                 Threshold Threshold Counter       Counter       Counter
------- -------- --------- --------- ------------- ------------- -------------
Fa3/1   cdp           ----      ----             0             0             0
        stp           ----      ----             0          1090             0
        vtp           ----      ----             0             0             0
POS4/1/ cdp           ----      ----           n/a           n/a           n/a
        stp           ----      ----           n/a           n/a           n/a
        vtp           ----      ----           n/a           n/a           n/a
Router#
The counter is not supported for Layer 2 protocol tunneling for BCP; therefore, "n/a" is displayed.

Configuring Multipoint Bridging

Multipoint bridging (MPB) enables point-to-multipoint bridging for ATM permanent virtual circuits (PVCs) and Frame Relay data-link connection identifiers (DLCIs). This feature allows the use of multiple VCs or DLCIs per VLAN for bridging on the Enhanced FlexWAN module.

Multipoint bridging allows service providers to add support for Ethernet-based Layer 2 services to the proven technology of their existing ATM and Frame Relay legacy networks. Customers can then use their current VLAN-based networks over the ATM or Frame Relay cloud. This also allows service providers to gradually update their core networks to the latest Gigabit Ethernet optical technologies, while still supporting their existing customer base.

ATM interfaces use RFC 1483 bridging, and Frame Relay interfaces use RFC 1490 bridging, both of which provide an encapsulation method to allow the transport of Ethernet frames over each type of Layer 2 network.

Note RFC 1483 has been obsoleted and superseded by RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5. RFC 1490 has been obsoleted and superseded by RFC 2427, Multiprotocol Interconnect over Frame Relay. To avoid confusion, this document continues to use the original RFC numbers.

Beginning in Cisco IOS Release 12.2(18)SXE, multipoint bridging supports the following modes of operation:

•Raw (default)—Default bridging access mode, in which the bridged connection acts on and transmit bridge protocol data unit (BPDU) packets.

•Access—Access-only bridging access mode, in which the bridged connection does not act on or transmit BPDU packets.

•802.1Q—Performs IEEE 802.1Q tagging to preserve the class of service (CoS) information from the Ethernet frames across the ATM network.

•802.1Q Tunnel—IEEE 802.1Q tunneling mode, so that service providers can use one VLAN to support customers with multiple VLANs, as well as accept untagged frames.

For information about the QoS over bridging feature, which provides QoS services for bridged Ethernet packets, see the "Configuring QoS on Bridged Interfaces" section on page 5-31.

Restrictions and Usage Guidelines

The following restrictions and usage guidelines apply to the multipoint bridging feature:

•Supported only on the Enhanced FlexWAN module.

•On ATM interfaces, only PVCs are supported. Switched virtual circuits (SVCs) are not supported.

•Multipoint bridging on Frame Relay interfaces supports only IETF encapsulation. Cisco encapsulation is not supported for multipoint bridging.

•VLAN id 1 is not available as a bridge domain for doing multipoint bridging.

•Multipoint bridging supports an absolute maximum of 60 VCs per each VLAN, and an absolute maximum number of VLANs per peer is 4096. We recommend configuring at most 30 VCs per VLAN, with at most 1024 VLANs per VC.

Prerequisites

The following prerequisites apply to multipoint bridging support on the Enhanced FlexWAN module:

•Multipoint Bridging is supported on the following port adapter interfaces:

–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

–PA-H

–PA-2H

–PA-POS-OC3MM

–PA-POS-OC3SMI

–PA-POS-OC3SML

–PA-POS-2OC3

•To use VLANs in multipoint bridging, you must use the vlan command to manually add those VLANs to the VLAN database.

•The bridge-vlan command has been renamed bridge-domain and options were added to support multipoint bridging. In existing configurations, the bridge-vlan command is automatically renamed to bridge-domain in the running-config when the system is upgraded to Release 12.2(18)SXE. Be sure to save the running-config to startup-config to make these changes permanent.

Multipoint Bridging Configurations

This section describes how to configure multipoint bridging on the following interfaces:

•Configuring Multipoint Bridging for ATM Interfaces

•Configuring Multipoint Bridging for Frame-Relay Interfaces

Configuring Multipoint Bridging for ATM Interfaces

This section describes how to configure multipoint bridging on ATM interfaces. You can configure multipoint bridging on individual PVCs or on a range of PVCs. To perform either task or both, use the following procedure.

Summary Steps

1. enable

2. configure terminal

3. vlan {vlan-id | vlan-range}

4. interface interface-type slot/bay/port

5. no ip address

Note Configuring an IP address on a bridged interface is not recommended.

6. interface atm slot/subslot/port.subinterface [point-to-point | multipoint]

Use the following two commands (pvc and bridge-domain) to create and configure PVCs individually. Repeat these commands as desired.

7. pvc [name] vpi/vci

8. bridge-domain vlan-id [access | dot1q | dot1q-tunnel] [ignore-bpdu-pid] [split-horizon]

Use the following two commands (range pvc and bridge-domain) to create and configure a range of PVCs. Repeat these commands as desired.

9. range [range-name] pvc [start-vpi/]start-vci [end-vpi/]end-vci

10. bridge-domain start-vlan-id [access | dot1q | dot1q-tunnel] [ignore-bpdu-pid] [increment] [split-horizon]

11. end

Command or Action

Purpose

Step 1

enable
Example:

Router> enable
Router#

Enables privileged EXEC mode. Enter your password if prompted.

Step 2

configure terminal
Example:

Router# configure terminal
Router(config)#

Enters global configuration mode.

Step 3

vlan {vlan-id | vlan-range}
Example:

Router(config)# vlan 2,5,10-12,20,25,4000
Router(config-vlan)#

Adds the specified VLAN IDs to the VLAN database and enters VLAN configuration mode.

•vlan-id—Specifies a single VLAN ID. The valid range is from 2 to 4094.

•vlan-range—Specifies multiple VLAN IDs, as either a list or a range. The vlan-range can contain a list of the VLAN IDs, separated either by a comma (,), dash (-), or both.

Note Before you can use a VLAN for multipoint bridging, you must manually enter its VLAN ID into the VLAN database.

Step 4

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

Router(config)# interface atm 8/0/0
Router(config-if)#

Enters configuration mode for the specified ATM interface.

Step 5

no ip address
Example:

Router(config-if)# no ip address
Router(config-if)#

Removes the IP address on the main interface.

Step 6

interface atm slot/subslot/port.subinterface [point-to-point | multipoint]
Example:

Router(config-if)# interface atm 8/0/0.100 multipoint
Router(config-subif)#

(Optional) Enters configuration mode for the specified subinterface, assuming that you are using subinterfaces to organize the PVCs.

•point-to-point—Creates a point-to-point connection.

•multipoint—Allows multiple PVCs to use the same VLAN.

Use the following two commands (pvc and bridge-domain) to create and configure PVCs individually. Repeat these commands as desired.

Step 7

pvc [name] vpi/vci
Example:

Router(config-if)# pvc 10/100
Router(config-if-atm-vc)#

Configures a new ATM PVC with the specified VPI and VCI numbers:

•name—(Optional) Descriptive name to identify this PVC.

•vpi/vci—Virtual path identifier (VPI) and virtual channel identifier (VCI) for this PVC.

Step 8

bridge-domain vlan-id [access | dot1q | dot1q-tunnel] [ignore-bpdu-pid] [split-horizon]
Example:

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

Enables RFC 1483 bridging to map a bridged VLAN to a PVC. The following options are supported:

Note This command has additional options that are not supported in a multipoint bridging configuration.

•vlan-id—Number of VLAN to be used in this bridging configuration. The valid range is from 2 to 4094 (but the VLAN ID must have been previously added to the VLAN database in Step 3).

Note This is the default configuration; frames are not tagged with the dot1q header but STP BPDUs are transmitted.

•access—Enables bridging access mode, so that the bridged connection does not act on or transmit BPDUs.

•dot1q—(Optional) Terminates dot1q traffic. Also enables IEEE 802.1Q tagging to preserve the class of service (CoS) information from the Ethernet frames across the ATM network. Without this option, the COS values are not preserved.

•dot1q-tunnel—(Optional) Enables IEEE 802.1Q tunneling mode, so that service providers can use one VLAN to support customers with multiple VLANs, as well as accept untagged frames.

Note The access, dot1q, and dot1q-tunnel options are mutually exclusive. If you do not specify any of these options, the connection operates in "raw" bridging access mode, which is similar to access, except that the connection does act on and transmit BPDU packets.

•ignore-bpdu-pid—(Optional, ATM interfaces only) Ignores bridge protocol data unit (BPDU) packets, to allow interoperation with ATM customer premises equipment (CPE) devices that do not distinguish BPDU packets from data packets.

•split-horizon—(Optional) Enables RFC 1483 split horizon mode to globally prevent bridging between PVCs in the same VLAN.

Note In Cisco IOS Release 12.2(18)SXE and later releases, the atm bridge-enable command is no longer supported on the Enhanced FlexWAN module. Instead, use the bridge domain command to enable ATM RFC 1483 bridging.

Use the following two commands (range pvc and bridge-domain) to create and configure a range of PVCs. Repeat these commands as desired.

Step 9

range [range-name] pvc [start-vpi/]start-vci [end-vpi/]end-vci
Example:

Router(config-if-atm-vc)# range pvc 1/121 1/180
Router(config-if-atm-range)#

Creates a range of PVCs and enters PVC range configuration mode:

•range-name—(Optional) Descriptive name of the range, up to a maximum of 15 characters.

•start-vpi/—(Optional) Beginning value for the range of virtual path identifiers (VPIs). The valid range is from 0 to 255, with a default of 0.

•start-vci—Beginning value for a range of virtual channel identifiers (VCIs). The valid range is from 32 to 65535.

•end-vpi—End value for the range of VPIs. The valid range is from 0 to 255, with a default that is equal to the start-vpi value.

•end-vci—End value for a range of virtual channel identifiers (VCIs). The vci value ranges from 32 to 65535.

Step 10

bridge-domain vlan-id [access | dot1q | dot1q-tunnel] [ignore-bpdu-pid] [increment] [split-horizon]
Example:

Router(config-if-atm-range)# bridge-domain 121 increment
Router(config-if-atm-range)#

Enables RFC 1483 bridging to map a bridged VLAN to the configured range of PVCs. In addition to the options that are shown in Step 8, this command supports the following option when used in PVC range configuration mode:

•increment—Increments the bridge domain number for each PVC in the range.

Step 11

end
Example:

Router(config-if-atm-range)# end
Router#

Exits VC or PVC range configuration mode and returns to privileged EXEC mode.

The following example shows a range of PVCs and an individual PVC configured for multipoint bridging:
interface ATM5/0/0
 no ip address
 shutdown
!
interface ATM5/0/0.1 multipoint
 range pvc 0/105 0/107
  bridge-domain 105 access increment
 !
 pvc 0/108 
  bridge-domain 108 dot1q
 !
!
interface ATM5/1/0
 no ip address
 load-interval 30
 range pvc 1/121 1/180
  bridge-domain 121 increment
 !
!
Verification

To display information about the PVCs that have been configured on ATM interfaces, use the following commands:

•show atm pvc—Displays a summary of the PVCs that have been configured.

•show atm vlan—Displays the connections between PVCs and VLANs.

Tip Use the show atm vlan command instead of the show interface trunk command to display information about ATM interfaces being used for multipoint bridging.

The following shows an example of each command.
Router# show atm pvc 
           VCD /                                        Peak  Avg/Min Burst
Interface  Name         VPI   VCI  Type   Encaps   SC   Kbps   Kbps   Cells  Sts
5/0/0      1              0    102 PVC    SNAP     UBR  599040                UP
5/0/0      2              0    103 PVC    SNAP     UBR  599040                UP
5/0/0      3              0    111 PVC    SNAP     UBR  599040                UP
5/0/0      3              0    111 PVC    SNAP     UBR  599040                UP
5/0/0      3              0    111 PVC    SNAP     UBR  599040                UP
Router# show atm vlan 
Options Legend:  DQ - dot1q;  DT - dot1q-tunnel;  MD - multi-dot1q; 
                 AC - access; SP - split-horizon; BR - broadcast; 
                 IB - ignore-bpdu-pid;
                 DEF - default 
Interface              VCD    VPI      Network   Customer   PVC     Options 
                              /VCI     Vlan ID   Dot1Q-ID   Status 
ATM5/0/0                1     0/102       102     1002        UP    MD
ATM5/0/0                2     0/103       103     1003        UP    MD
ATM5/0/0                3     0/111       111     1111        UP    MD
ATM5/0/0                3     0/111       112     1112        UP    MD
ATM5/0/0                3     0/111       113     1113        UP    MD
Router# 
Configuring Multipoint Bridging for Frame-Relay Interfaces

This section describes how to configure multipoint bridging on Frame-Relay interfaces. You can configure multipoint bridging on individual DLCI circuits. You can optionally add 802.1Q tagging or 802.1Q tunneling.

To perform this configuration, use the following procedure:

Summary Steps

1. enable

2. configure terminal

3. vlan {vlan-id | vlan-range}

4. interface iftype slot/subslot/port

5. no ip address

6. encapsulation frame-relay ietf

Note The encapsulation frame-relay ietf command does not work with Cisco encapsulation.

7. interface iftype slot/subslot/port.subinterface {multipoint | point-to-point}

8. frame-relay interface-dlci dlci [ietf]

9. bridge-domain vlan-id [access | dot1q | dot1q-tunnel] [split-horizon]

10. end

Note ChOC-12 does not support the bridge-domain command.

Detailed Configuration Procedure

Command or Action

Purpose

Step 1

enable
Example:

Router> enable
Router#

Enables privileged EXEC mode. Enter your password if prompted.

Step 2

configure terminal
Example:

Router# configure terminal
Router(config)#

Enters global configuration mode.

Step 3

vlan {vlan-id | vlan-range}
Example:

Router(config)# vlan 2,5,10-12,20,25,4000
Router(config-vlan)#

Adds the specified VLAN IDs to the VLAN database and enters VLAN configuration mode.

•vlan-id—Specifies a single VLAN ID. The valid range is from 1 to 4094 (but VLAN 1 is not supported for multipoint bridging).

•vlan-range—Specifies multiple VLAN IDs, as either a list or a range. The vlan-range can contain a list of the VLAN IDs, separated either by a comma (,), dash (-), or both.

Note You must manually enter a VLAN ID into the VLAN database before you can use that VLAN for multipoint bridging.

Step 4

interface iftype slot/port
or
interface iftype slot/subslot/port
Example:

Router(config)# interface pos 4/1/0
Router(config-if)#

Enters configuration mode for the specified interface.

Step 5

no ip address
Example:

Router(config-if)# no ip address
Router(config-if)#

Removes the IP address, if any, that is configured on the interface.

Step 6

encapsulation frame-relay ietf
Example:

Router(config-if)# encapsulation frame-relay ietf
Router(config-if)#

Enables Frame Relay encapsulation on the interface, using IETF encapsulation. You must specify the ietf keyword either here or in Step 8 for each individual DLCI.

Note Multipoint bridging does not support Cisco encapsulation using the cisco keyword.

Step 7

interface iftype slot/port.subinterface {multipoint | point-to-point}
or
interface iftype slot/subslot/port.subinterface {multipoint | point-to-point}
Example:

Router(config-if)# interface pos 4/1/0.21
Router(config-subif)#

Enters configuration mode for the specified subinterface.

Step 8

frame-relay interface-dlci dlci [ietf]
Example:

Router(config-subif)# frame-relay interface-dlci 28
Router(config-fr-dlci)#

Creates the specified DLCI on the subinterface and enters DLCI configuration mode.

•dlci—DLCI number to be used on the specified subinterface.

•ietf—(Optional) Specifies IETF encapsulation. This option is required if you did not specify IETF encapsulation in Step 6.

Note This command includes other options that are not supported when using multipoint bridging.

Step 9

bridge-domain vlan-id [access | dot1q | dot1q-tunnel] [split-horizon]
Example:

Router(config-fr-dlci)# bridge-domain 100 dot1q-tunnel
Router(config-fr-dlci)#

Enables RFC 1483 bridging to map a bridged VLAN to a PVC. The following options are supported:

Note This command has additional options that are not supported in a multipoint bridging configuration.

•vlan-id—Number of VLAN to be used in this bridging configuration. The valid range is from 2 to 4094 (but the VLAN ID must have been previously added to the VLAN database in Step 3).

Note This is the default configuration; frames are not tagged with the dot1q header but STPs and BPDUs are transmitted.

•access—Enables bridging access mode, so that the bridged connection does not act on or transmit BPDUs.

•dot1q—(Optional) Terminates dot1q traffic. Also enables IEEE 802.1Q tagging to preserve the class of service (CoS) information from the Ethernet frames across the ATM network. Without this option, the COS values are not preserved.

•dot1q-tunnel—(Optional) Enables IEEE 802.1Q tunneling mode, so that service providers can use one VLAN to support customers with multiple VLANs, as well as accept untagged frames.

Note The access, dot1q, and dot1q-tunnel options are mutually exclusive. If you do not specify any of these options, the connection operates in "raw" bridging access mode, which is similar to access, except that the connection does act on and transmit BPDU packets.

•ignore-bpdu-pid—(Optional, ATM interfaces only) Ignores bridge protocol data unit (BPDU) packets, to allow interoperation with ATM customer premises equipment (CPE) devices that do not distinguish BPDU packets from data packets.

Note split-horizon—(Optional) Enables RFC 1483 split horizon mode to globally prevent bridging between PVCs in the same VLAN.

Note ChOC-12 does not support the bridge-domain command.

Step 10

end
Example:

Router(config-fr-dlci)# end
Router#

Exits DLCI configuration mode and returns to privileged EXEC mode.

The following is an example of a Multipoint Bridging configuration on a Frame-Relay interface:
frame-relay switching
...
!
interface POS3/8/0
 no ip address
 encapsulation frame-relay ietf 
 logging event link-status
 clock source internal
 frame-relay intf-type dce
!
interface POS3/8/0.10 multipoint
 frame-relay interface-dlci 120
  bridge-domain 100 dot1q-tunnel
 frame-relay interface-dlci 130
  bridge-domain 100 dot1q-tunnel
Configuring Bridged Routing Encapsulation

Bridged routing encapsulation (BRE) enables an ATM OC-3 port adapter to receive RFC 1483 routed encapsulated packets and forward them as Layer 2 frames. In a BRE configuration, the PVC receives the routed PDUs, removes the RFC 1483 routed encapsulation header, and adds an Ethernet MAC header to the packet. The Layer 2 encapsulated packet is then switched by the supervisor engine or route switch processor to the Layer 2 interface determined by the VLAN number and destination MAC.

Note This feature is supported in Cisco IOS Release 12.2(18)SXE and later releases.

Figure 3-2 shows a topology in which an interface on an ATM OC-3 port adapter receives routed PDUs from the ATM cloud and encapsulates them as Layer 2 frames. It then forwards the frames to the Layer 2 customer device.

Figure 3-2 Example BRE Topology

Bridged Routing Encapsulation Configuration Guidelines

•PVCs must use AAL5SNAP encapsulation.

•A BRE PVC is not a bridged connection and is not included in the show vlan id bre-vlan command output.

•A BRE-connected VLAN cannot be used by other BRE PVCs on other bridging features, such as RFC 1483, RFC 1490, and Bridge Control Protocol (BCP).

•Bridging between BRE PVCs is not supported.

•BRE carries only IP traffic. Everything else is dropped.

•For FlexWAN, Enhanced FlexWAN, and SIP-1, BRE is allowed on the main interface and both point-to-point and multipoint subinterfaces.

Command or Action

Purpose

Step 1

Router# configure terminal

Enters global configuration mode.

Step 2

Router(config)# interface atm slot/subslot/port

Enters interface configuration mode for the indicated port on the specified port adapter.

Step 3

Router(config-if)# no ip address

Assigns no IP address to the interface.

Step 4

Router(config-if)# spanning-tree bpdufilter enable

(Optional) Blocks all Spanning Tree BPDUs on the ATM interface. This command should be used if this ATM interface is configured only for BRE VLANs.

Note If this ATM interface is configured for both BRE and RFC 1483 bridged VLANs, do not enter this command unless you want to explicitly block BPDUs on the interface.

Step 5

Router(config-if)# no shutdown

Enables the interface.

Step 6

Router(config-if)# interface atm slot/subslot/port.subinterface point-to-point

Creates the specified point-to-point subinterface on the given port on the specified ATM port adapter, and enters subinterface configuration mode.

Step 7

Router(config-subif)# no ip address

Assigns no IP address to the subinterface.

Step 8

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

Configures a new ATM PVC by assigning its VPI/VCI numbers and enters ATM VC configuration mode. The valid values for vpi/vci are:

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

•vci—Specifies the VCI. 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.

You can also configure the following options:

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

•ilmi—(Optional) Configures the PVC to use ILMI encapsulation (default).

•qsaal—(Optional) Configures the PVC to use QSAAL encapsulation.

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

Step 9

Router(config-if-atm-vc)# bre-connect vlan-id [mac mac-address]

Enables BRE bridging on the PVC.

•vlan-id—A string that identifies the VLAN.

•mac mac-address—(Optional) Specifies the hardware (MAC) address of the destination customer premises equipment (CPE) device at the remote end of the VLAN connection.

Step 10

Router(config-if-atm-vc)# interface gigabitethernet slot/port

Enters interface configuration mode for the specified Gigabit Ethernet interface.

Step 11

Router(config-if)# switchport

Configures the Gigabit Ethernet interface for Layer 2 switching.

Step 12

Router(config-if)# switchport access vlan vlan-id

(Optional) Specifies the default VLAN for the interface. This should be the same VLAN ID that was specified in the bre-connect command in Step 9.

Step 13

Router(config-if)# switchport mode access

Puts the interface into nontrunking mode.

Step 14

Router(config-if)# end

Exits interface configuration mode and returns to privileged EXEC mode.

Verifying the Bridged Routing Encapsulation Configuration

Use the following show commands to verify the bridged routing encapsulation configuration:
Router# show running-config interface atm 5/0/2.1 
!
interface ATM5/0/2.1 point-to-point
 pvc 0/100 
  bre-connect 100
!
Router# show running-config interface atm 5/0/2.1 
!
interface ATM5/0/2.1 point-to-point
 pvc 0/100 
  bre-connect 100 mac 0001.bbb.cccc
!
Router# show running-config interface gigabitethernet 1/2 
interface GigabitEthernet1/2
 no ip address
 switchport
 switchport access vlan 100 
 no cdp enable
!
Router# show atm vlan 
Interface       BRE VCD         Vlan ID
ATM5/0/2.1      1                   100 
Router# 
!
Router# show atm vlan bre
!
Interface       BRE VCD    VPI/VCI   VLAN Learned MAC    Virtual MAC
ATM4/1/0.300    7          10/300   300 0001.bbbb.cccc   0000.0410.0007
Configuring Frame Relay (RFC 1490) Bridging

Frame Relay Bridging, as described in RFC 1490, allows packets to be encapsulated (using SNAP) for transmission across a Frame Relay network. The bridged packet is SNAP-encapsulated inside the Frame Relay frame. This feature provides the following:

•Remote bridging through a Frame Relay virtual circuit (VC)

•One VLAN per VC

•Multiple VCs per VLAN

•Support of tagged and untagged packet formats

–On a tagged VC, untagged packets are dropped.

•Support of Dot1q tunneling

•Support of split-horizon

–If the packet comes in through a WAN bridged interface, then it is not sent out of another WAN bridged interface.

Port Adapters Supported

RFC 1490 bridging is supported on the following port adapters

•PA-HSSI (PA-H and PA-2H)

•PA-MC-xT1/E1(+)

•PA-MC-xT3(+)

•PA-MC-STM-1

This feature supports the following standards:

•RFC 1490 Multiprotocol interconnect over Frame Relay

Note RFC 1490 has been replaced by RFC 2427. To simplify the discussion, RFC 1490 is used in this document.

Configuration Tasks

To configure RFC 1490 Bridging on FlexWAN, use the following commands beginning in global configuration mode:
Command

Purpose
Step 1
Router(config)# interface pos 
module_num/bay/port
Specifies the interface to configure.
Step 2
Router(config-if)# frame-relay 
interface-dlci dlci-number
Links a DLCI number to the interface.
Step 3
Router(config-fr-dlci)# bridge-vlan 
vlan-id [access | broadcast] [dot1q | 
dot1q-tunnel] [lan-fcs] [split-horizon]
vlan-id: Binds the VLAN to the VC.

access: Use bridge access mode.

broadcast: Use bridge broadcast mode.

dot1q: Include 802.1q VLAN tag in Ethernet frames.

dot1q-tunnel: Use 802.1q tunneling mode.

lan-fcs: Ethernet frames will preserve lan-fcs.

split-horizon: Use split-horizon mode.

Note In Cisco IOS Release 12.2(18)SXE and later releases, the bridge-vlan command has been renamed bridge-domain and options were added to support multipoint bridging.
Enhancements to RFC 1483 and RFC 1490 Spanning Tree Interoperability

This section describes an interoperability feature for the various spanning-tree implementations across 1483 Bridge Mode ATM PVCs. Historically, vendors have not implemented spanning-tree across RFC 1483 encapsulation consistently; furthermore, some Cisco IOS releases may not support the full range of spanning-tree options. This feature attempts to smooth some of the practical challenges of interworking common variations of spanning-tree over RFC 1483 and RFC 1490 Bridge Mode encapsulation.

Note This feature set is only supported on RFC 1483 and RFC 1490 Bridge Mode permanent virtual circuits (PVCs).

Here are definitions for the basic terms:

•IEEE 802.1D is a standard for interconnecting LANs through media access control (MAC) bridges. IEEE 802.1D uses the Spanning-Tree Protocol to eliminate loops in the bridge topology, which cause broadcast storms.

•Spanning Tree Protocol (STP) as defined in IEEE 802.1D is a link-management protocol that provides path redundancy while preventing undesirable loops in the network. An IEEE 802.1D spanning tree makes it possible to have one spanning tree instance for the whole switch, regardless of the number of VLANs configured on the switch.

•Bridge Protocol Data Unit (BPDU) is the generic name for the frame used by the various spanning-tree implementations. The Spanning Tree Protocol uses the BPDU information to elect the root switch and root port for the switched network, as well as the root port and designated port for each switched segment.

•Per VLAN Spanning Tree (PVST) is a Cisco proprietary protocol that allows a Cisco device to support multiple spanning tree topologies on a per-VLAN basis. PVST uses the BPDUs defined in IEEE 802.1D (see Figure 3-4), but instead of one STP instance per switch, there is one STP instance per VLAN.

•PVST+ is a Cisco proprietary protocol that creates one STP instance per VLAN (as in PVST). However, PVST+ enhances PVST and uses Cisco proprietary BPDUs with a special 802.2 Subnetwork Access Protocol (SNAP) Organizational Unique Identifier (OUI)¹ (see Figure 3-4) instead of the standard IEEE 802.1D frame format used by PVST. PVST+ BPDUs are also known as Simple Symmetric Transmission Protocol (SSTP) BPDUs.

Note RFC 1483 is referenced throughout this section, although it has been superseded by RFC 2684.

Supported Supervisor Engines and Line Cards

The Cisco 7600 routers support PVST to PVST+ BPDU interoperability with the following supervisor engines and line cards:

Route Switch Processor 720 and Supervisor Engine 720 Line Cards

•Enhanced FlexWAN

•FlexWAN

•Cisco 7600 SIP-200

•ATM Optical Services Module (OSM)

Supervisor Engine 2 Line Cards

•Enhanced FlexWAN

•FlexWAN

•ATM Optical Services Module (OSM)

The Interoperability Problem

The current interoperability problem can be summarized as follows:

•When transmitting STP BPDUs, many vendors' implementations of ATM-to-Ethernet bridging are not fully compliant with the specifications of RFC 1483, Appendix B. The most common variation of the standard is to use an ATM Common Part Convergence Sublayer (CPCS) SNAP protocol data unit (PDU) with OUI: 00-80-C2 and PID: 00-07. Appendix B reserved this OUI/PID combination for generic Ethernet frames without BPDUs. Appendix B specifies OUI: 00-80-C2 and protocol identifier (PID): 00-0E for frames with BPDU contents.

•There are several varieties of the Spanning-Tree protocol used by Cisco products on ATM interfaces. The Catalyst 5000 series supports only PVST on ATM interfaces. The Cisco 7600 router and Catalyst 6500 series switches support only PVST+ on ATM interfaces. Most other Cisco routers implement classic IEEE 802.1D on ATM interfaces.

When the Cisco 7600 series router and the Catalyst 6500 series switch first implemented 1483 Bridging (in Cisco IOS Release 12.1E) on the Cisco 7600 FlexWAN module, the platform used OUI: 00-80-C2 and PID: 00-0E to maximize interoperability with all other Cisco IOS products.

However, there are so many implementations that do not send PVST or IEEE 802.1D BPDUs with PID: 00-0E that the Cisco 7600 series and the Catalyst 6500 series reverted to the more common implementation of RFC 1483 (with PID: 00-07) in Cisco IOS Release 12.2SX. This spanning tree interoperability feature provides the option of encapsulating BPDUs across RFC 1483 with either PID: 00-07 or PID: 00-0E.

BPDU Packet Formats

The various BPDU packet formats are described in this section. Figure 3-3 shows the generic IEEE 802.2/802.3 frame format, which is used by PVST+,—but is not used by PVST.

Figure 3-3 IEEE 802.2/802.3 SNAP Encapsulation Frame Format

In an Ethernet SNAP frame, the SSAP and DSAP fields are always set to AA. These codes identify it as a SNAP frame. The Control field always has a value of 03, which specifies connectionless logical link control (LLC) services.

The Type field identifies the upper layer protocol to which data should be passed. For example, a Type field of hex 0800 represents IP, while a value of 8137 indicates that data is meant for IPX.

Catalyst 5000 PVST BPDU Packet Format

Catalyst 5000 series switches send and receive BPDUs in PVST format on ATM interfaces (see Figure 3-4).

Figure 3-4 BPDU PVST Frame Format Used by the Catalyst 5000 Switch

•BPDUs sent by the Catalyst 5000 switch use a PID of 0x00-07, which does not comply with RFC 1483. The Cisco 7600 series router also has the ability to send BPDUs in this data format.

•The PAD portion of the ATM encapsulation varies from 0 to 47 bytes in length to ensure complete ATM cell payloads.

•By using the bridge-domain command's ignore-bpdu-pid optional keyword, the Catalyst 5000 switch sends this frame by default (for details, see the "BPDU Translation Command Line Interface Summary" section).

•The Catalyst 5000 switch cannot accept the PVST+ BPDUs and blocks the ATM port, giving the following error message:

%SPANTREE-2-RX_1QNON1QTRUNK: Rcved 1Q-BPDU on non-1Q-trun port 6/1 vlan 10

%SPANTREE-2-RX_BLKPORTPVID: Block 6/1 on rcving vlan 10 for inc peer vlan 0

Cisco 7200 and Cisco 7500 Routers IEEE 802.1D BPDU Frame Format

Figure 3-5 shows the Cisco 7200 and Cisco 7500 series routers IEEE 802.1D BPDU frame format:

Figure 3-5 Frame Format for the Cisco 7200 and Cisco 7500 Routers IEEE 802.1D BPDU

Cisco 7600 Router PVST+ BPDU Frame Format

The Cisco 7600 series router PVST+ BPDU packet format is shown in Figure 3-6. These BPDUs are not IEEE 802.1D BPDUs, but Cisco proprietary SSTP BPDUs.

Figure 3-6 Cisco 7600 Router PVST+ BPDU Frame Format (1483 Bridge Mode)

Cisco L2PT BPDU Frame Format

Figure 3-7 shows the Cisco Layer 2 Protocol Tunneling (L2PT) BPDU SNAP frame format.

Figure 3-7 L2PT BPDU SNAP Frame Format

BPDU Translation Command Line Interface Summary

In order to resolve the interoperability problem, Cisco has introduced the following new keywords for the bridge-domain command:

•ignore-bpdu-pid

•pvst-tlv

The ignore-bpdu-pid Keyword

Without the ignore-bpdu-pid keyword, the permanent virtual circuit (PVC) between the devices operates in an RFC 1483-compliant manner, which is referred to as strict mode. Using the ignore-bpdu-pid keyword is known as loose mode.

•Without this keyword, IEEE BPDUs are sent out using a PID of 0x00-0E, which complies with RFC 1483.

•With this keyword, IEEE BPDUs are sent out using a PID of 0x00-07, which is normally reserved for RFC 1483 data.

For details, refer to the "BPDU Packet Formats" section.

Cisco proprietary PVST+ BPDUs are always sent out as data frames using a PID of 0x00-07, regardless of whether the ignore-bpdu-pid keyword is used.

Use the ignore-bpdu-pid keyword when connecting to devices that send PVST (or IEEE 802.1D) BPDUs with PID: 00-07. This includes the vast majority of customer premises equipment (CPE) devices, such as ATM Digital Subscriber Line (DSL) modems.

The pvst-tlv Keyword

The pvst-tlv keyword enables BPDU translation when interoperating with devices that understand only PVST or Spanning Tree Protocol. Because the Cisco 7600 ATM modules support PVST+ only, the pvst-tlv keyword must be used when connecting to a Catalyst 5000 switch, which only understands PVST on its ATM modules, or when connecting with other Cisco IOS routers, which understand IEEE format only.

•When transmitting, the pvst-tlv keyword translates PVST+ BPDUs into IEEE BPDUs.

•When receiving, the pvst-tlv keyword translates IEEE BPDUs into PVST+ BPDUs.

When a Cisco 7600 Series Router Is Connected to a Cisco 7200 Series Router

The Cisco 7200 series router only understands IEEE BPDUs in an RFC 1483-compliant manner. Thus, when a Cisco 7600 series router is connected to a Cisco 7200 series router, the keywords used should be as follows:

bridge-domain vlan pvst-tlv vlan

The ignore-bpdu-pid keyword is not used in this case because the Cisco 7200 router must operate in an RFC 1483-compliant manner for IEEE BPDUs.

When a Cisco 7600 Series Router Is Connected to a Catalyst 5500 ATM Module

The Catalyst 5500 ATM module only understands PVST BPDUs in a non-RFC 1483-compliant manner. Therefore, when a Cisco 7600 series router is connected to a Catalyst 5500 ATM module, both keywords are required:

bridge-domain vlan ignore-bpdu-pid pvst-tlv vlan

Layer 2 Protocol Tunneling Topology CLI

To enable BPDU translation for the Layer 2 Protocol Tunneling (L2PT) topologies, use the following command line:

bridge-domain PE vlan dot1q-tunnel ignore-bpdu-pid pvst-tlv CE vlan

Typical Topologies Requiring BPDU Translation

This section describes the most common network scenarios and provides the configuration commands necessary to enable BPDU translation between the devices in each example.

Layer 2 Protocol Tunneling Topology with a Cisco 7600, Catalyst 5500, and Catalyst 6500

Figure 3-8 shows one sample network topology in which data packets are sent between a Catalyst 6500 switch and a Cisco 7600 series router.

Figure 3-8 Catalyst 5500 Switch, 6500 Switch, and Cisco 7600 Series Router in an L2PT Topology

As shown in Figure 3-8, Layer 2 Protocol Tunneling (L2PT) is configured at the Cisco 7600 ATM 6/1/0 interface and also at the Catalyst 6500 switch Gig 2/1 interface.

PVST packets are sent from the Catalyst 5500 switch to the Cisco 7600 series router. The Cisco 7600 router transports those BPDUs by way of L2PT and sends them to the Catalyst 6500 switch. Those BPDUs are decapsulated and restored before sending the packets out to the customer network.

The Cisco 7600 router and the Catalyst 6500 switch are provider edge (PE) devices and the rest are customer edge (CE) devices.

ATM Configuration Example

Any traffic coming in must be sent via a dot1q-tunnel. If the PE VLAN is 200 and the CE VLAN is 100, you have the following configuration:

Router(config)# interface atm 6/1/0

Router(config-if)# pvc 6/200

Router(config-if-atm-vc)# bridge-domain 200 dot1q-tunnel ignore-bpdu-pid pvst-tlv 100

Ethernet Configuration Example

An example of the Ethernet configuration follows:

Router(config)# interface gig2/1

Router(config-if)#switchport

Router(config-if)#switchport access vlan 200

Router(config-if)#switchport mode dot1q-tunnel

Router(config-if)# l2protocol-tunnel

CE VLAN 100 is what is used at the customer sites. The Catalyst 5500 switch sends the IEEE BPDU in data format. The Cisco 7600 router receives the BPDU and first converts it to PVST+ format. Then the destination address (DA) MAC of the frame is changed to the protocol tunnel MAC address and sent out into the Layer 2 cloud.

At the other end, when the frame leaves the Gig 2/1 interface, the DA MAC is changed back to the PVST+ DA MAC and the PVST+ BPDU is sent to the CPE device.

Layer 2 Protocol Tunneling Topology with a Cisco 7600 and Cisco 7200

In this example, a Cisco 7600 series router needs to communicate with a Cisco 7200 series router.

Figure 3-9 Cisco 7600 and Cisco 7200 Routers in an L2PT Topology

PE Configuration

On the PE routers, the configuration appears as follows:
!On PE 1
interface ATM2/0/0
no ip address
atm mtu-reject-call
pvc 7/101
bridge-domain 200 dot1q-tunnel
!
end
!On PE 2
interface ATM3/0/0
no ip address
pvc 2/101
bridge-domain 200 dot1q-tunnel pvst-tlv 100
!
end
Cisco 7600 CE Configuration

The configuration for the Cisco 7600 CE 1 router would be as follows:
!On CE 1
interface ATM1/1/0
no ip address
atm mtu-reject-call
pvc 7/101
bridge-domain 101
!
end
Cisco 7200 CE Configuration

The configuration for the Cisco 7200 CE 2 router would be as follows:
!On CE 2
interface ATM4/0
no ip address
no atm ilmi-keepalive
pvc 2/101
!
bridge-group 101
end
Data Transmission Sequence from the Cisco 7200 CE to the Cisco 7600 CE

Given the configurations and topologies shown in these examples, the data transmission sequence from the Cisco 7200 CE to the Cisco 7600 CE is as follows:

1. The Cisco 7200 CE 2 router sends BPDUs without the MAC header in RFC 1483 format.

2. The Cisco 7600 PE router receives the packets and then translates the IEEE BPDU into PVST+ BPDU format.

3. VLAN 100 is inserted into the PVST+ BPDU.

4. The frame's destination address (DA) MAC value is rewritten to use the protocol tunnel DA MAC and is sent out into the ATM network cloud.

5. The L2PT BPDU must go out of the PE 1 ATM 2/0/0 interface. The DA MAC is restored to the PVST+ DA MAC.

6. Finally, the PVST+ BPDU is sent to the Cisco 7600 CE 1 router.

Cisco 7600 Basic Back-to-Back Scenario

Figure 3-10 shows an example of a basic back-to-back scenario.

Figure 3-10 Cisco 7600 Routers in Basic Back-to-Back Topology

The PDUs exchanged are PVST+ BPDUs. The PVST+ BPDUs are sent using a PID of 0x00-07. The configuration is set as follows:

Router(config)# interface atm 2/1/0

Router(config-if)# pvc 2/202

Router(config-if-atm-vc)# bridge-domain 101

Catalyst 5500 Switch and Cisco 7600 Series Routers in Back-to-Back Topology

Another sample topology is a simple back-to-back setup, which serves to test basic Catalyst 5500 and Cisco 7600 interoperability.

Figure 3-11 Catalyst 5500 Switch and Cisco 7600 Routers in Back-to-Back Topology

When connected to a device that sends and receives IEEE BPDUs in data format (PID 0x00-07) like the Catalyst 5000 ATM module, the configuration must be something like this:

Router(config)# interface atm 2/1/0

Router(config-if)# pvc 2/202

Router(config-if-atm-vc)# bridge-domain 101 ignore-bpdu-pid pvst-tlv 101

The Cisco 7600 router translates its outgoing PVST+ BPDUs into IEEE BPDUs. Because the ignore-bpdu-pid keyword is also enabled, the BPDU uses a PID of 0x00-07, which is exactly what the Catalyst 5500 switch requires.

Cisco 7600 and Cisco 7200 in Back-to-Back Topology

When connecting to a device that is completely RFC 1483 compliant, in which the IEEE BPDUs are sent using a PID of 0x00-0E, you must use the new ignore-bpdu-pid keyword in the bridge-domain command.

Figure 3-12 Cisco 7600 Router Series and Cisco 7200 Router Series in Back-to-Back Topology

For example, when a Cisco 7600 series router is connected to a Cisco 7200 series router, the configuration would be as follows:

Router(config)# interface atm 2/1/0

Router(config-if)# pvc 2/202

Router(config-if-atm-vc)# bridge-domain 101 pvst-tlv 101

Note In this scenario, the CE VLAN number must be identical to the bridge-domain VLAN number.

¹The Organizational Unique Identifier (OUI) portion of the MAC address often identifies the vendor of the upper layer protocol or the manufacturer of the Ethernet adapter. The OUI value of 00-00-0C identifies Cisco Systems as the manufacturer of the Ethernet adapter.