FlexWAN and Enhanced FlexWAN Software Features Configuration Information

Transcription

1 CHAPTER 3 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. 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). 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 Deprecation feature document at: 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, page 3-2 Configuring Private Hosts Switched Virtual Interface (VLAN and VPLS), page 3-4 Configuring Half-Bridging, page 3-8 Configuring Distributed Network-Based Application Recognition, page 3-9 Configuring Distributed Network-Based Application Recognition, page 3-9 Configuring IGMP Snooping, page 3-9 Configuring ACFC and PFC Support on Multilink Interfaces, page 3-10 Configuring Distributed Multilink Point-to-Point Protocol, page 3-13 Configuring Multilink Frame Relay, page 3-16 Configuring Distributed Link Fragmentation and Interleaving for Frame Relay and ATM Interfaces, page 3-21 Configuring Compressed Real-Time Protocol (CRTP), page

2 Configuring ATM VC Access Trunk Emulation Configuring Voice over Frame Relay (VoFR) FRF.11 and FRF.12, page 3-41 Configuring Frame Relay Virtual Circuit (VC) Bundling, page 3-64 Configuring Routed Bridged Encapsulation, page 3-64 Configuring Bridging Control Protocol Support, page 3-69 Configuring Multipoint Bridging, page 3-81 Configuring Bridged Routing Encapsulation, page 3-91 Configuring Frame Relay (RFC 1490) Bridging, page 3-94 Enhancements to RFC 1483 and RFC 1490 Spanning Tree Interoperability, page 3-95 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: 3-2

3 Configuring ATM VC Access Trunk Emulation 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: 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. Step 3 Router(config-if-atm-vc)# bridge-domain vlan-id dot1q dot1q-id 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. 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/ UP MD ATM3/0/0 1 1/ UP MD ATM3/0/0 1 1/ UP MD ATM3/0/0 1 1/ UP MD ATM3/0/0 1 1/ UP MD 3-3

4 Configuring Private Hosts Switched Virtual Interface (VLAN and VPLS) CBR, SusRate: 2300 AAL5-LLC/SNAP, etype:0x0, Flags: 0x , 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: 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 ================================================================================ x x x x x 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. 3-4

5 Configuring Private Hosts Switched Virtual Interface (VLAN and VPLS) 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 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: 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. 3-5

6 Configuring Private Hosts Switched Virtual Interface (VLAN and VPLS) Step 4 Step 5 Router(config)# [no] private-hosts vlan-list vlan-id Router(config)# [no] private-hosts promiscous mac-list-name [vlan-list vlan ids] (Optional) Provides a list of VLANs to be isolated. The no form of the command removes the specified VLANs from the isolated VLAN list. The VLAN- list also programs the promiscuous devices' MAC addresses. (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: Router# show private-hosts configuration Router# show private-hosts access-lists Router# show private-hosts interface configuration Router# show private-hosts mac-list Router-sp# show private-hosts vlans Router-sp# show private-hosts index Displays the global private host configuration. Displays the access lists related to the private hosts. Displays the ports on which the feature is enabled with the configured mode. Displays the configured MAC lists and their members. Displays the VPLS-enabled VLANs related to the private hosts. 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 pw-class mpls Router(config)# private-hosts vlan-list , Router(config)# private-hosts promiscuous maclist-1 Router(config)# private-hosts promiscuous maclist-2 Router(config)# private-hosts mac-list maclist Router(config)# private-hosts mac-list maclist Router(config)# private-hosts layer3 3-6

7 Configuring Private Hosts Switched Virtual Interface (VLAN and VPLS) 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 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 , Router(config)# private-hosts promiscuous maclist-1 Router(config)# private-hosts promiscuous maclist-2 Router(config)# private-hosts mac-list maclist Router(config)# private-hosts mac-list maclist Router(config)# private-hosts layer3 Router(config)# private-hosts!router(config)# interface GigabitEthernet3/1 Router(config-if)#switchport Router(config-if)# switchport access vlan

8 Configuring Half-Bridging 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 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: Step 1 Step 2 Router(config)# interface atm mod_num/bay/port [.subinterface-number multipoint] Router(config-subif)# ip address ip-address subnet-mask Specifies the subinterface on which to configure half-bridging. 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 Router(config-subif)# ip mtu 1500 Router(config-subif)# pvc 5/100 Router(config-subif-atm-vc)# encapsulation aal5snap bridge 3-8

9 Configuring Distributed Network-Based Application Recognition 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. 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: 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. 3-9

10 Configuring ACFC and PFC Support on Multilink Interfaces 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. Address and control field compression is only applicable to links that use PPP in HDLC-like framing as described by RFC Restrictions and Usage Guidelines ACFC and PFC should be configured with the link shut down. 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 3-10

11 Configuring ACFC and PFC Support on Multilink Interfaces 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: 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. Step 4 Router(config-if)# shutdown Shuts down the interface. Step 5 slot/subslot/port:channel-group Specifies the location of the interface. 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. 3-11

12 Configuring ACFC and PFC Support on Multilink Interfaces 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: 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. Step 4 Router(config-if)# shutdown Shuts down the interface Step 5 slot/subslot/port:channel-group Specifies the location of the interface. 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 3-12

13 Configuring Distributed Multilink Point-to-Point Protocol 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. 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 on page 3-72 for more information. Restrictions and Usage Guidelines The following restrictions apply to the Distributed Multilink PPP feature: 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. 3-13

14 Configuring Distributed Multilink Point-to-Point Protocol 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 T1/E1 Port Adapters Channelized T3/E3 Port Adapters STM-1 Port Adapter Port Adapters Supported 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-E3 PA-MC-T3 PA-MC-2T3+ PA-MC-STM-1 Configuration Tasks See the following sections for configuration tasks for the dmlppp feature. Enabling Distributed CEF Switching Enabling Distributed CEF Switching, page 3-14 (required) Creating a Multilink Bundle, page 3-15 (required) Assigning an Interface to a Multilink Bundle, page 3-15 (required) Disabling PPP Multilink Fragmentation, page 3-16 (optional) Verifying the Configuration, page 3-16 (optional) 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: 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 3-14

15 Configuring Distributed Multilink Point-to-Point Protocol Creating a Multilink Bundle To create a multilink bundle, use the following commands beginning in global configuration mode: Step 1 Step 2 Router(config)# interface multilink group-number Router(config-if)# ip address address mask Step 3 Router(config-if)# encapsulation ppp Enables PPP encapsulation. Step 4 Router(config-if)# ppp multilink Enables Multilink PPP. Enters multilink interface configuration mode and creates a multilink bundle (where group-number is a non-zero number to use to identify the bundle). Assigns an IP address to the multilink interface. The following is an example of creating a multilink bundle: Router# interface multilink1 Router# ip address 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: 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

16 Configuring Multilink Frame Relay Disabling PPP Multilink Fragmentation By default, PPP multilink fragmentation is enabled. To disable PPP multilink fragmentation, use the following command in interface configuration mode: Router(config-if)# no ppp multilink fragmentation Disable PPP multilink fragmentation. Verifying the Configuration 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. 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. 3-16

17 Configuring Multilink Frame Relay 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. 3-17

18 Configuring Multilink Frame Relay 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, page 3-18 (required) Configuring a Multilink Frame Relay Bundle Link, page 3-18 (required) Verifying Multilink Frame Relay, page 3-19 (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: Configuring a Multilink Frame Relay Bundle Link 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. To configure a bundle link interface for Multilink Frame Relay, use the following commands beginning in global configuration mode: 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. 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. 3-18

19 Configuring Multilink Frame Relay Step 3 Router(config-if)# frame-relay multilink lid name (Optional) Assigns a bundle link identification name to a multilink Frame Relay bundle link. 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. 3-19

20 Configuring Multilink Frame Relay 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: Router# debug frame-relay multilink [control [mfr number serial number]] Router# show frame-relay multilink [mfr number serial number] [detailed] Router# show interfaces mfr number Displays debug messages for multilink Frame Relay bundles and bundle links. Displays configuration information and statistics about multilink Frame Relay bundles and bundle links. Displays information and packet statistics for the bundle interface. 3-20

21 Configuring Distributed Link Fragmentation and Interleaving for Frame Relay and ATM Interfaces 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 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. 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. 3-21

22 Configuring Distributed Link Fragmentation and Interleaving for Frame Relay and ATM Interfaces 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 Without dlfi Voice pkt Data pkt With dlfi Voice pkt Data pkt Voice pkt Data pkt 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 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). 3-22

23 Configuring Distributed Link Fragmentation and Interleaving for Frame Relay and ATM Interfaces 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. 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 3-23