Cisco 7600 Series Router SIP, SSC, and SPA Software Configuration Guide
Configuring the SIPs and SSC
Downloads: This chapterpdf (PDF - 1.68MB) The complete bookPDF (PDF - 13.93MB) | Feedback

Table of Contents

Configuring the SIPs and SSC

Configuration Tasks

Required Configuration Tasks

Identifying Slots and Subslots for SIPs, SSCs, and SPAs

Specifying the Slot Location for a SIP or SSC

Specifying the SIP or SSC Subslot Location for a SPA

Configuring Compressed Real-Time Protocol

CRTP Configuration Guidelines

Configuring Frame Relay Features

Configuring Distributed Multilink Frame Relay ( FRF.16) on the Cisco 7600 SIP-200

Configuring Distributed Multilink PPP on the Cisco 7600 SIP-200

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

Frame Relay Fragmentation (FRF.12)

Restrictions

Configuring FRF.12 on SIP-400

Configuring Voice over Frame Relay FRF.11 and FRF.12

Configuring Layer 2 Interworking Features on a SIP

Configuring Bridging for ATM Interfaces (RFC 1483/RFC 2684)

Configuring Multipoint Bridging

Verification

Configuring Private Hosts SVI (Interface VLAN)

Configuring Private Hosts over Virtual Private LAN Service (VPLS)

Restrictions and Guidelines

Configuration Steps

Verifying the Private Hosts on the VPLS Configuration

Configuring PPP Bridging Control Protocol Support

Configuring Virtual Private LAN Service

Configuring Asymmetric Carrier-Delay

Configuring BFD over VCCV on SIP-400

Configuration Restrictions

Configuration Steps

Verifying BFD VCCV Configuration

Debugging the BFD Configuration

Configuring MPLS Features on a SIP

Configuring Any Transport over MPLS on a SIP

Configuring Hierarchical Virtual Private LAN Service (H-VPLS) with MPLS to the Edge

Configuring VRF aware IPv6 tunnel

Configuring MPLS Traffic Engineering Class-Based Tunnel Selection (CBTS) on the Cisco 7600 SIP-600

Troubleshooting

Configuring QoS Features on a SIP

General QoS Feature Configuration Guidelines

Configuring QoS Features Using MQC

Configuring QoS Traffic Classes on a SIP

Configuring QoS Class-Based Marking Policies on a SIP

Configuring QoS Congestion Management and Avoidance Policies on a SIP

Configuring Dual-Priority Queuing on a Cisco 7600 SIP-400

Configuring Hierarchical Queuing Framework on a Cisco 7600 SIP-400

Configuring Priority Percent on a Policy-Map on a Cisco 7600 SIP-400

Configuring Percent Priority and Percent Bandwidth Support on a Cisco 7600 SIP-400

Ingress HQF on Cisco 7600 SIP-400

Restrictions for Ingress HQF

Configuring Ingress HQF on Cisco 7600 SIP-400

Configuration Example for Ingress HQF

Verifying Ingress HQF

Configuring QoS Traffic Shaping Policies on a SIP

Configuring QoS Traffic Policing Policies on a SIP

Attaching a QoS Traffic Policy to an Interface

Configuring Network-Based Application Recognition and Distributed Network-Based Application Recognition

Configuring Hierarchical QoS on a SIP

Configuring PFC QoS on a Cisco 7600 SIP-600

Configuring NAT

Restrictions

Configuring Lawful Intercept on a Cisco 7600 SIP-400

Configuring Security ACLs on an Access Interface on a Cisco 7600 SIP-400

Security ACL Configuration Guidelines

Configuring Security ACL

Verifying ACL Configuration

Configuring CoPP on the Cisco7600 SIP-400

Configuring Per-Subscriber/Per-Protocol CoPP on Access Interfaces on a Cisco 7600 SIP-400

Configuring Per-Subinterface CoPP on Access Interfaces on a Cisco 7600 SIP-400

Configuring DBUS COS Queuing on SIP-400

Configuration Guidelines and Restrictions

Configuration Steps

Verifying the DBUS COS Queuing Configuration

Configuring IPv6 Hop-by-Hop Header Security on SIP-200 or SIP-400

Usage Guidelines

Supported Supervisor Engines and SPAs

Configuring IPv6 Hop-by-Hop Header Security

Verifying the IPv6 Hop-By-Hop Policing Configuration

Triple Nesting QoS Support on SIP400

Configuration and Restrictions

Configuration procedure

Configuration Samples

Example of Third Level User Defined Egress QoS Policy-Map

Example of Third Level User Defined Ingress QoS Policy-Map

Example of Third Level User Defined QoS Policy-Map for ATM

Configuring IGMP Snooping on a SIP-200

Configuring ACFC and PFC Support on Multilink Interfaces

About ACFC and PFC

Restrictions and Usage Guidelines

Supported Platforms

Configuring ACFC and PFC Support

Configuring PPPoEoE on a Cisco7600 SIP-400

Supported Features

Limitations and Restrictions

Configuration Tasks for PPPoE over Ethernet

Configuring Source IPv4 and Source MAC Address Binding on the SIP-400

Configuration Guidelines

Restrictions

Configuring Source IPv4 and Source MAC Address Binding

Resetting a SIP

Configuration Examples

Layer 2 Interworking Configuration Examples

BCP in Trunk Mode Configuration Example

BCP in Single-VLAN Mode Configuration Example

MPLS Configuration Examples

Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Class-Based Tunnel Selection (CBTS) Configuration Example

QoS Configuration Examples

QoS with Multipoint Bridging Configuration Examples

Hierarchical QoS with 2-Level Policy Map Configuration Examples

Private Hosts SVI (Interface VLAN) Configuration Example

Troubleshooting

Configuring the SIPs and SSC

This chapter provides information about configuring SIPs and SSCs on the Cisco 7600 series router. It includes the following sections:

For information about managing your system images and configuration files, refer to the Cisco IOS Configuration Fundamentals Configuration Guide and Cisco IOS Configuration Fundamentals Command Reference publications that correspond to your Cisco IOS software release.

For more information about the commands used in this chapter,refer to the Cisco IOS Software Releases 15.0SR Command References and to the Cisco IOS Software Releases 12.2SX Command References . Also refer to the related Cisco IOS Release 12.2 software command reference and master index publications. For more information, see the “$paratext>” section.

Configuration Tasks

This section describes how to configure the SIPs and SSCs and includes information about verifying the configuration.

It includes the following topics:

This section identifies those features that have SIP-specific configuration guidelines for you to consider and refers you to the supporting platform documentation.

Many of the Cisco IOS software features on the Cisco 7600 series router that the FlexWAN and Enhanced FlexWAN modules support, the SIPs also support. Use this chapter while also referencing the list of supported features on the SIPs in Chapter4, “Overview of the SIPs and SSC”


NoteWhen referring to the other platform documentation, be sure to note any SIP-specific configuration guidelines described in this document.Layer 2 Interworking Configuration Examples


For information about configuring other features supported on the Cisco 7600 series router but not discussed in this document, refer to the Cisco 7600 Series Cisco IOS Software Configuration Guide, 12.2S R at the following URL:

http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/swcg.html


NoteEffective 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 theLegacy 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


Required Configuration Tasks

As of Cisco IOS Release 12.2(18)SXE, there are not any features that require direct configuration on the SIP or SSC. This means that you do not need to attach to the SIP or SSC itself to perform any configuration.

However, the Cisco 7600 SIP-200 and Cisco 7600 SIP-400 do implement and support certain features that are configurable at the system level on the Route Processor (RP).

Identifying Slots and Subslots for SIPs, SSCs, and SPAs

This section describes how to specify the physical locations of a SIP and SPA on the Cisco 7600 series routers within the command-line interface (CLI) to configure or monitor those devices.


NoteFor simplicity, any reference to “SIP” in this section also applies to the SSC.


Specifying the Slot Location for a SIP or SSC

The Cisco 7600 series router supports different chassis models, each of which supports a certain number of chassis slots.


NoteThe Cisco 7600 series router SIPs are notsupported with a Supervisor Engine 1, Supervisor Engine 1A, Supervisor Engine 2, or Supervisor Engine 720-3A.


Figure 5-1 shows an example of a SIP installed in slot 6 on a Cisco 7609 router. The Cisco 7609 router has nine vertically-oriented chassis slots, which are numbered 1 to 9 from right to left.

Figure 5-1 SIP and SPA Installed in a Cisco 7609 Router

 

 

1

SIP subslot 0

4

SIP subslot 3

2

SIP subslot 1

5

Chassis slots 1–9 (numbered from right to left)

3

SIP subslot 2

 

 

Some commands allow you to display information about the SIP itself, such as show module , show sip-disk , show idprom module , show hw-module slot , and show diagbus . These commands require you to specify the chassis slot location where the SIP that you want information about is installed.

For example, to display status and information about the SIP installed in slot 6 as shown in Figure 5-1, enter the following command:

Router# show module 6
 

For more information about the commands used in this chapter, refer to the Cisco IOS Software Releases 15.0SR Command References and to the Cisco IOS Software Releases 12.2SX Command References ..

Specifying the SIP or SSC Subslot Location for a SPA

SIP subslots begin their numbering with “0” and have a horizontal or vertical orientation depending on the orientation of the SIP in the router chassis slot, as shown in the “SIP, SSC, and SPA Product Overview” chapter of the Cisco 7600 Series Router SIP, SSC, and SPA Software Configuration Guide .

Figure 5-1 shows an example of a Cisco 7600 SIP-200 installed with a vertical orientation on a Cisco 7609 router. The Cisco 7600 SIP-200 supports four subslots for the installation of SPAs. In this example, the subslot locations are vertically oriented as follows:

  • SIP subslot 0—Top–right subslot
  • SIP subslot 1—Bottom–right subslot
  • SIP subslot 2—Top–left subslot
  • SIP subslot 3—Bottom–left subslot

Figure 5-2 shows the faceplate for the Cisco 7600 SIP-200 in a horizontal orientation.

Figure 5-2 Cisco 7600 SIP-200 Faceplate

 

In this view, the subslot locations in a horizontal orientation are as follows:

  • SIP subslot 0—Top–left subslot
  • SIP subslot 1—Top–right subslot
  • SIP subslot 2—Bottom–left subslot
  • SIP subslot 3—Bottom–right subslot

The SIP subslot numbering is indicated by a small numeric label beside the subslot on the faceplate.

Just as with the SIPs, some commands allow you to display information about the SPA itself, such as show idprom module and show hw-module subslot . These commands require you to specify both the physical location of the SIP and SPA in the format, slot / subslot , where:

  • slot —Specifies the chassis slot number in the Cisco 7600 series router where the SIP is installed.
  • subslot —Specifies the secondary slot of the SIP where the SPA is installed.

For example, to display the operational status for the SPA installed in the first subslot of the SIP in chassis slot 6 shown in Figure 5-1, enter the following command:

Router# show hw-module subslot 6/0 oir
 

For more information about the commands used in this chapter, refer to the Cisco IOS Software Releases 15.0SR Command References and to the Cisco IOS Software Releases 12.2SX Command References .

Configuring Compressed Real-Time Protocol

Compressed Real-Time Protocol (CRTP), from RFC 1889 ( RTP: A Transport Protocol for Real-Time Applications ), 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. CRTP is supported over Frame Relay, ATM, PPP, distributed MLPPP (dMLPPP), and HDLC encapsulated interfaces.

Table 5-1 provides information about where the CRTP feature for SPA interfaces is supported.

 

Table 5-1 CRTP Feature Compatibility by SIP and SPA Combination

Feature
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

Hardware-based CRTP

In Cisco IOS Release 12.2(18)SXE and later:

  • 8-Port Channelized T1/E1 SPA
  • 2-Port and 4-Port Channelized T3 SPA

Not supported.

Not supported.

Hardware- and software-based CRTP

In Cisco IOS Release 12.2(33)SRA:

  • 8-Port Channelized T1/E1 SPA
  • 2-Port and 4-Port Channelized T3 SPA
  • 1-Port Channelized OC-3/STM-1 SPA

Not supported.

Not supported.

CRTP with dLFIoLL—Only supported with one link present on the multilink interface

In Cisco IOS Release 12.2(18)SXE and later:

  • 8-Port Channelized T1/E1 SPA
  • 2-Port and 4-Port Channelized T3 SPA

Support for the following SPA was added in Cisco IOS Release 12.2(33)SRA:

  • 1-Port Channelized OC-3/STM-1 SPA

Not supported.

Not supported.

CRTP with dMLPPP

Supported. Not supported if LFI is enabled.

Not supported.

Not supported.

CRTP with dMLPPP and MPLS

Not supported.

Not supported.

Not supported.

CRTP Configuration Guidelines

To support CRTP on the Cisco 7600 SIP-200, consider the following guidelines:

  • High-level Data Link Control (HDLC), PPP, or Frame Relay encapsulation must be configured.
  • TCP or RTP header compression, or both, must be enabled.
  • 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.
  • When using CRTP with distributed features on the Cisco 7600 SIP-200, consider the following guidelines and restrictions:

Hardware- and software-based CRTP is supported with Distributed Link Fragmentation and Interleaving over Leased Lines (dLFIoLL) if only one link is present on the multilink interface.

The following restrictions apply to Multilink PPP interfaces that use LFI:

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.

CRTP should not be configured on a multilink interface when LFI is enabled on the multilink interface if the multilink bundle has more than one member link, and a QoS policy with a feature is enabled on the multilink interface.


Note In a dMLPPP/dLFI configuration, packets do not carry the MLPPP header and sequence number. Thus, MLPPP distributes the packets across all member links. As a result, packets that are compressed by CRTP may arrive out-of-order at the receiving router. This prohibits CRTP from decompressing the packet header and forces CRTP to drop the packets.


For information on configuring CRTP, see Configuring Distributed Compressed Real-Time Protocol at the following URL:

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

Configuring Frame Relay Features

Many of the Frame Relay features supported on the FlexWAN and Enhanced FlexWAN modules on the Cisco 7600 series router are also supported by the SIPs. For a list of the supported Frame Relay features on the SIPs, see Chapter4, “Overview of the SIPs and SSC”

This section describes those Frame Relay features that have SIP-specific configuration guidelines. After you review the SIP-specific guidelines described in this document, then refer to the referenced URLs for more information about configuring Frame Relay features.

The Frame Relay features for SIPs and SPAs are qualified as distributed features because the processing for the feature is handled by the SIP or SPA, or a combination of both.

Configuring Distributed Multilink Frame Relay (FRF.16) on the Cisco 7600 SIP-200

The Distributed Multilink Frame Relay (dMLFR) 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 the User-Network Interface (UNI) and the Network-to-Network Interface (NNI) in Frame Relay networks.


NoteFor the Cisco 7600 SIP-200 line card, dMLFR support can be either software based on the7600 SIP-200 or hardware based on the 8-Port Channelized T1/E1 SPA, 2-Port and 4-Port Channelized T3 SPAs and 1-Port Channelized OC-3/STM-1 SPA, depending on your link configuration. For more information about the hardware-based configuration, see also“Configuring the 8-Port Channelized T1/E1 SPA,”, Chapter20, “Configuring the 2-Port and 4-Port Channelized T3 SPAs” and Chapter 25, “Configuring the 1-Port Channelized OC3/STM-1 SPA”. For 7600 SIP-400 line cards, dMLFR support is hardware based.



NoteEffective with 15.2(4)S, you cannot configure an IP address on a serial link that would be part of the MLFR or MLPPP bundle.During upgrade to Cisco IOS release 15.2(4)S from older versions, you should remove the IP address from member links and then perform the upgrade if IP address is already configured on the member links.


Table 5-2 provides information about the supported SPAs for the dMLFR feature.

 

Table 5-2 dMLFR Feature Compatibility by SIP and SPA Combination

Feature
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

dMLFR

In Cisco IOS Release 12.2(18)SXE and later:

  • 8-Port Channelized T1/E1 SPA
  • 2-Port and 4-Port Channelized T3 SPA

In Cisco IOS Release 12.2(33)SRA and later:

  • 1-Port Channelized OC-3/STM-1 SPA

In Cisco IOS Release 15.2(4)S and later:

  • 8-Port Channelized T1/E1 SPA
  • 2-Port and 4-Port Channelized T3 SPA
  • 1-Port Channelized OC-3/STM-1 SPA
  • 1-Port Channelized OC-12/STM-4 SPA

Not supported.

This section includes the following topics:

Overview of dMLFR

The Distributed 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 within 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.

For link management, each end of a bundle link follows the MLFR link integrity protocol and exchanges link control messages with its peer (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 will resend the hello message up to a configured maximum number of times. If the router exhausts the maximum number of retries, the bundle link line protocol is considered down (unoperational).

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 becomes 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 line protocol remains up as long as the LMI keepalives are successful.

dMLFR Configuration Guidelines

To support dMLFR on the Cisco 7600 SIP-200 or Cisco 7600 SIP-400 consider the following guidelines:

  • dMLFR must be configured on the peer device.
  • The dMLFR peer device must not send frames that require assembly.
  • Distributed links are supported under the following conditions:

All links should be on the same line card.

T1 and E1 links cannot be mixed in a bundle.

Member links in a bundle are recommended to have the same bandwidth.

  • QoS is implemented on the SIP line card.
  • dMLFR is supported with Frame Relay over MPLS (FRoMPLS) on the Cisco 7600 SIP-200 or Cisco 7600 SIP-400 line card between the customer edge (CE) and provider edge (PE) of the MPLS network.
  • Only RPR+ High Availability (HA) feature is supported with dMLFR.
  • Cisco 7600 SIP-200 supports dMLFR in software or in the SPA hardware based on the link configuration. dMLFR support for Cisco 7600 SIP-400 is hardware based.
  • For Cisco 7600 SIP-200, dMLFR is supported in the software if bundle link members are on different SPAs in the same Cisco 7600 SIP-200 line card.

Software-Based Guidelines

dMLFR will be implemented in the software if any of the following conditions are met:

  • Any one bundle link member is a fractional T1 or E1 link.
  • There are more than 12 T1 or E1 links in a bundle.

Hardware-Based Guidelines

dMLFR will be implemented in the hardware when all of the following conditions are met:

  • All bundle link members are T1 or E1 only.
  • All bundle links are on the same SPA.
  • There are no more than 12 links in a bundle.

dMLFR Restrictions

When configuring dMLFR on the Cisco 7600 SIP-200, consider the following restrictions:

  • FRF.9 hardware compression is not supported.
  • Software compression is not supported.
  • Encryption is not supported.
  • The maximum differential delay supported is 50 ms when supported in hardware, and 100 ms when supported in software.
  • Fragmentation is not supported on the transmit side.

dMLFR Configuration Tasks

The following sections describe how to configure dMLFR:

Creating a Multilink Frame Relay Bundle


SUMMARY STEPS


Step 1 interface mfr number

Step 2 frame-relay multilink bid name

Step 3 frame-relay intf-type dce

DETAILED STEPS

To configure the bundle interface for dMLFR, 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 and enters interface configuration mode, where:

  • number—Specifies the number for the Frame Relay bundle.

Step 2

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

(Optional) Assigns a bundle identification name to a multilink Frame Relay bundle, where:

  • name—Specifies the name for the Frame Relay bundle.

Note The bundle identification (BID) will not go into 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 by using the shutdown and no shutdown commands in interface configuration mode.

Step 3

Router(config-if)# frame-relay intf-type dce

Configures the router to function as a digital communications equipment (DCE) device, or as a switch.

Assigning an Interface to a dMLFR Bundle

To configure an interface link and associate it as a member of a dMLFR bundle, use the following commands beginning in global configuration mode. Repeat these steps to assign multiple links to the dMLFR bundle.

SUMMARY STEPS


Step 1 interface serial address
OR
interface serial slot / subslot / port / t1-number : channel-group
OR
interface serial slot/ subslot / port : channel-group

Step 2 encapsulation frame-relay mfr number [name]

Step 3 frame-relay multilink lid name

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

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

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

DETAILED STEPS

If you use this task to assign more than 12 T1 or E1 interface links as part of the same bundle, or if any of the T1/E1 interface links are fractional T1/E1, or any links reside on multiple SPAs as part of the same bundle, then software-based dMLFR is implemented automatically by the Cisco 7600 SIP-200.

 

Command
Purpose

Step 1

1-Port Channelized OC-3/STM-1 SPA and 1-Port Channelized OC12 /STM-4 SPA

Router(config)# interface serial address

2-Port and 4-Port Channelized T3 SPA

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

8-Port Channelized T1/E1 SPA

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

Specifies a serial interface and enters interface configuration mode, where:

  • address —For the different supported syntax options for the address argument for the 1-Port Channelized OC-3/STM-1 SPA and 1-Port Channelized OC-12/STM-4 SPA, refer to the “Interface Naming” section of the “Configuring the 1-Port Channelized OC-3/STM-1 SPA” chapter.
  • slot —Specifies the chassis slot number where the SIP is installed.
  • subslot —Specifies the secondary slot number on a SIP where a SPA is installed.
  • port —Specifies the number of the interface port on the SPA.
  • t1-number —Specifies the logical T1 number in channelized mode.
  • channel-group—Specifies the logical channel group assigned to the time slots within the T1 or E1 group.

Note If you configure a fractional T1/E1 interface on the SPA using a channel group and specify that fractional T1/E1 channel group as part of this task, then software-based dMLFR is implemented automatically by the Cisco 7600 SIP-200 when you assign the interface to the dMLFR bundle.

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, where:

  • number—Specifies the number for the Frame Relay bundle. This number should match the dMLFR interface number specified in the interface mfr command.
  • name—(Optional) Specifies the name for the Frame Relay bundle.

Step 3

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

(Optional) Assigns a bundle link identification name with a multilink Frame Relay bundle link, where:

  • name—Specifies the name for the Frame Relay bundle.

Note The bundle link identification (LID) will not go into 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 by using the shutdown and no shutdown 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, where:

  • seconds—Specifies the number of seconds between hello messages sent out over the multilink bundle. The default 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, where:

  • seconds—Specifies the number of seconds a bundle link will wait for a hello message acknowledgment before resending the hello message. The default 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, where:

  • number—Specifies the maximum number of times a bundle link will resend a hello message while waiting for an acknowledgment. The default is 2 tries.

Verifying dMLFR

To verify dMLFR configuration, use the show frame-relay multilink command. If you use the show frame-relay multilink command without any options, information for all bundles and bundle links is displayed.

The following examples show output for the show frame-relay multilink command with the serial number and detailed options. Detailed information about the specified bundle links is displayed.

Router# show frame-relay multilink serial6 detailed
 
Bundle: MFR49, State = down, class = A, fragmentation disabled
BID = MFR49
No. of bundle links = 1, Peer's bundle-id =
Bundle links:
 
Serial6/0/0:0, HW state = up, link state = Add_sent, LID = test
Cause code = none, Ack timer = 4, Hello timer = 10,
Max retry count = 2, Current count = 0,
Peer LID = , RTT = 0 ms
Statistics:
Add_link sent = 21, Add_link rcv'd = 0,
Add_link ack sent = 0, Add_link ack rcv'd = 0,
Add_link rej sent = 0, 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

Configuring Distributed Multilink PPP on the Cisco 7600 SIP-200

The Distributed Multilink Point-to-Point Protocol (dMLPPP) feature allows you to combine T1/E1 lines into a bundle that has the combined bandwidth of multiple T1/E1 lines. This is done by using a dMLPPP link. You choose the number of bundles and the number of T1/E1 lines in each bundle. This allows you to increase the bandwidth of your network links beyond that of a single T1/E1 line without having to purchase a T3 line.


NoteBased on your link configuration, dMLPPP can be either software-based on the Cisco 7600 SIP-200, or hardware-based on the 8-Port Channelized T1/E1 SPA and 2-Port and 4-Port Channelized T3 SPAs. For more information about the hardware-based configuration, see also“Configuring the 8-Port Channelized T1/E1 SPA,” Chapter20, “Configuring the 2-Port and 4-Port Channelized T3 SPAs”, and Chapter 25, “configuring the 1-Port Channelized OC3/STM-1 SPA.


SIP-200 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.


NoteOn SIP-400 shaping and policing is done without taking the MLP header into account.


Table 5-3 provides information about where the dMLppp feature for SPA interfaces is supported.

 

Table 5-3 dMLPPP Feature Compatibility by SIP and SPA Combination

Feature
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

Hardware-based dMLPPP

Supported

Not supported.

Not supported.

Hardware- and software-based dMLPPP

In Cisco IOS Release 12.2(18)SXE and later:

  • 8-Port Channelized T1/E1 SPA
  • 2-Port and 4-Port Channelized T3 SPA

In Cisco IOS Release 12.2(33)SRA and later:

  • 1-Port Channelized OC3/STM-1 SPA

Not supported.

Not supported.

This section includes the following topics:

dMLPPP Configuration Guidelines

dMLPPP is supported in software by the Cisco 7600 SIP-200, or in hardware by the supported SPA. This support is determined by your link configuration.

The Cisco 7600 SIP-200 supports distributed links under the following conditions:

  • All links are on the same Cisco 7600 SIP-200.
  • T1 and E1 links cannot be mixed in a bundle.
  • Member links in a bundle are recommended to have the same bandwidth.
  • Multilink interface creation is not supported beyond 65535. If you configure a multilink interface number that is more than 65535, on a switchover, you will experience a connectivity loss.
  • QoS is implemented on the Cisco 7600 SIP-200 for dMLPPP.

Software-Based Guidelines

dMLPPP will be implemented in the software if any of the following conditions are met:

  • Any one bundle link member is a fractional T1 or E1 link.
  • There are more than 12 T1 or E1 links in a bundle.
  • To enable fragmentation for software-based dMLPPP, you must configure the ppp multilink interleave command. This command is not required to enable fragmentation for hardware-based dMLPPP.

Hardware-Based Guidelines

dMLPPP will be implemented in the hardware when all of the following conditions are met:

  • All bundle link members are T1 or E1 only.
  • All bundle links are on the same SPA.
  • There are no more than 12 links in a bundle.

dMLPPP Restrictions

When configuring dMLPPP on the Cisco 7600 SIP-200, consider the following restrictions:

  • Hardware and software compression is not supported.
  • Encryption is not supported.
  • The maximum differential delay supported is 50 ms when supported in hardware, and 100 ms when supported in software.

dMLPPP Configuration Tasks

The following sections describe how to configure dMLPPP:

Enabling Distributed CEF Switching

To enable dMLPPP, you must first enable distributed CEF switching. Distributed CEF switching is enabled by default on the Cisco 7600 series router.


NoteWhen the value of the cef table is high due to high number of routes and the LC doesnot have enough memory, CEF gets disabled. New xconnect does not get activated on the device irrespective of LC being used or not used as ingress or egress LC.


SUMMARY STEPS


Step 1 ip cef distributed

DETAILED STEPS

To enable dCEF, use the following command in global configuration mode:

 

Command
Purpose

Router(config)# ip cef distributed

Enables distributed CEF switching.

Creating a dMLPPP Bundle

SUMMARY STEPS


Step 1 interface multilink group-number

Step 2 ip address ip-address mask

Step 3 ppp multilink interleave

Step 4 ppp multilink mrru local | remote mrru - value

Step 5 mtu bytes

Step 6 ppp multilink fragment delay delay

DETAILED STEPS

To configure a dMLPPP bundle, use the following commands beginning in global configuration mode:

 

Command
Purpose

Step 1

Router(config)# interface multilink group-number

Creates a multilink interface and enters interface configuration mode, where:

  • group-number—Specifies the group number for the multilink bundle.

NoteTo enableno interface multilink group-number, remove the associated multilink group for the member links using the command no ppp multilink.


Step 2

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

Sets the IP address for the multilink group, where:

  • ip-address —Specifies the IP address for the interface.
  • mask —Specifies the mask for the associated IP subnet.

Step 3

Router(config-if)# ppp multilink interleave

(Optional—Software-based LFI) Enables fragmentation for the interfaces assigned to the multilink bundle. Fragmentation is disabled by default in software-based LFI.

Step 4

Router(config-if)# ppp multilink mrru [ local | remote ] mrru - value

Configures the MRRU value negotiated on a multilink bundle when MLP is used.

  • local —(Optional) Configures the local MRRU value. The default values for the local MRRU are the value of the multilink group interface MTU for multilink group members, and 1524 bytes for all other interfaces.
  • remote —(Optional) Configures the minimum value that software will accept from the peer when it advertises its MRRU. By default, the software accepts any peer MRRU value of 128 or higher. You can specify a higher minimum acceptable MRRU value in a range from 128 to 16384 bytes.

Step 5

Router(config-if)# mtu bytes

(Optional) Adjusts the maximum packet size or MTU size.

  • Once you configure the MRRU on the bundle interface, you enable the router to receive large reconstructed MLP frames. You may want to configure the bundle MTU so the router can transmit large MLP frames, although it is not strictly necessary.
  • The maximum recommended value for the bundle MTU is the value of the peer’s MRRU. The default MTU for serial interfaces is 1500. The software will automatically reduce the bundle interface MTU if necessary, to avoid violating the peer’s MRRU.

Step 6

Router(config-if)# ppp multilink fragment delay delay

(Optional) Sets the fragmentation size satisfying the configured delay on the multilink bundle, where:

  • delay —Specifies the delay in milliseconds.

Assigning an Interface to a dMLPPP Bundle

To configure an interface PPP link and associate it as a member of a multilink bundle, use the following commands beginning in global configuration mode. Repeat these steps to assign multiple links to the dMLPPP bundle.


NoteIf you use this task to assign more than 12 T1 or E1 interface links as part of the same bundle, or if any of the T1/E1 interface links are fractional T1/E1, or any links reside on multiple SPAs as part of the same bundle, then software-based dMLPPP is implemented automatically by the Cisco 7600 SIP-200.


 

SUMMARY STEPS


Step 1 interface serial address
OR
interface serial slot / subslot / port / t1-number : channel-group
OR
interface serial slot/ subslot / port : channel-group
OR

Step 2 encapsulation ppp

Step 3 ppp multilink

Step 4 ppp authentication chap

Step 5 ppp chap hostname name

Step 6 ppp multilink group group-number


 

DETAILED STEPS

 

Command
Purpose

Step 1

1-Port Channelized OC-3/STM-1 SPA

Router(config)# interface serial address

2-Port and 4-Port Channelized T3 SPA

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

8-Port Channelized T1/E1 SPA

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

1 Port Channelized OC12/STM4 SPA

Router(config)# interface serial address

Specifies a serial interface and enters interface configuration mode, where:

  • address —For the different supported syntax options for the address argument for the 1-Port Channelized OC-3/STM-1 SPA, refer to the “Interface Naming” section of the “Configuring the 1-Port Channelized OC-3/STM-1 SPA” chapter.
  • slot —Specifies the chassis slot number where the SIP is installed.
  • subslot —Specifies the secondary slot number on a SIP where a SPA is installed.
  • port —Specifies the number of the interface port on the SPA.
  • t1-number —Specifies the logical T1 number in channelized mode.
  • channel-group—Specifies the logical channel group assigned to the time slots within the T1 or E1 group.

Note If you configure a fractional T1/E1 interface on the SPA using a channel group and specify that fractional T1/E1 channel group as part of this task, then software-based dMLPPP is implemented automatically by the Cisco 7600 SIP-200 when you assign the interface to the dMLPPP bundle.

Step 2

Router(config-if)# encapsulation ppp

Enables PPP encapsulation.


NoteTo enableno encapsulation ppp, remove the associated multilink group for the member links using the command no ppp multilink.


Step 3

Router(config-if)# ppp m ultilink

(Optional) Enables dMLPPP on the interface.

Step 4

Router(config-if)# ppp authentication chap

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

Step 5

Router(config-if)# ppp chap hostname name

(Optional) Assigns a name to be sent in the CHAP challenge.

  • name —Specifies an alternate username that will be used for CHAP authentication

Step 6

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

Assigns the interface to a multilink bundle, where:

  • group-number—Specifies the group number for the multilink bundle. This number should match the dMLPPP interface number specified in the interface multilink command.

Configuring Link Fragmentation and Interleaving over dMLPPP

Link fragmentation and interleaving (LFI) over dMLPPP is supported in software on the Cisco 7600 SIP-200, or in hardware on the 2-Port and 4-Port Channelized T3 SPA and the 8-Port Channelized T1/E1 SPA. This support is determined by your link configuration.

Software-Based Guidelines

When configuring LFI over dMLPPP, consider the following guidelines for software-based LFI:

  • LFI over dMLPPP will be configured in software if there is more than one link assigned to the dMLPPP bundle.
  • LFI is disabled by default in software-based LFI. To enable LFI on the multilink interface, use the ppp multilink interleave command.
  • Fragmentation size is calculated from the delay configured and the member link bandwidth.
  • You must configure a policy map with a class under the multilink interface.
  • CRTP should not be configured on a multilink interface when LFI is enabled on the multilink interface if the multilink bundle has more than one member link, and a QoS policy with a feature is enabled on the multilink interface.

Hardware-Based Guidelines

When configuring LFI over dMLPPP, consider the following guidelines for hardware-based LFI:

  • LFI over dMLPPP will be configured in hardware if you only assign one link (either T1/E1 or fractional T1/E1) to the dMLPPP bundle.
  • LFI is enabled by default in hardware-based LFI with a default size of 512 bytes. To enable LFI on the serial interface, use the ppp multilink interleave command.
  • A policy map having a class needs to be applied to the multilink interface.

Verifying dMLPPP

To verify dMLPPP configuration, use the show ppp multilink command, as shown in the following example:

Router# show ppp multilink
 
Multilink2, bundle name is group2
Bundle up for 00:01:21
Bundle is Distributed
0 lost fragments, 0 reordered, 0 unassigned
0 discarded, 0 lost received, 1/255 load
0x0 received sequence, 0x0 sent sequence
Member links: 2 active, 0 inactive (max not set, min not set)
Se4/3/0/1:0, since 00:01:21, no frags rcvd
Se4/3/0/1:1, since 00:01:19, no frags rcvd
 

If hardware-based dMLPPP is configured on the SPA, the show ppp multilink command displays “Multilink in Hardware” as shown in the following example:

Router# show ppp multilink
 
Multilink1, bundle name is group1
Bundle up for 00:00:13
Bundle is Distributed
0 lost fragments, 0 reordered, 0 unassigned
0 discarded, 0 lost received, 206/255 load
0x0 received sequence, 0x0 sent sequence
Member links: 2 active, 0 inactive (max not set, min not set)
Se4/2/0/1:0, since 00:00:13, no frags rcvd
Se4/2/0/2:0, since 00:00:10, no frags rcvd
Distributed fragmentation on. Fragment size 512. Multilink in Hardware.

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

The Distributed Link Fragmentation and Interleaving (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 dMLPPP 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 packets 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- 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 dMLPPP is also introduced as part of the dLFI feature.

For specific information about configuring dLFI, refer to the FlexWAN and Enhanced FlexWAN Module Installation and Configuration Note located at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/cfgnotes/flexport/combo/index.htm

For information about configuring dLFI on ATM SPAs, see the “Configuring Link Fragmentation and Interleaving with Virtual Templates” section in Chapter8, “Configuring the ATM SPAs”

Table 5-4 provides information about where the dLFI feature for SPA interfaces is supported.

 

Table 5-4 dLFI Feature Compatibility by SIP and SPA Combination

Feature
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

Hardware-based dLFI

In Cisco IOS Release 12.2(18)SXE and later:

  • 8-Port Channelized T1/E1 SPA
  • 2-Port and 4-Port Channelized T3 SPA

In Cisco IOS Release 12.2(18)SXE and later:

  • 2-Port OC-3c/STM-1 ATM SPA
  • 1-Port OC-12c/STM-4 ATM SPA

Not supported.

Hardware- and software-based dLFI

In Cisco IOS Release 12.2(33)SRA:

  • 8-Port Channelized T1/E1 SPA
  • 2-Port and 4-Port Channelized T3 SPA
  • 1-Port Channelized OC-3/STM-1 SPA

Not supported.

Not supported.

dLFI with MPLS

Not supported.

Not supported.

Not supported.

dLFI with MPLS on VPN

Supported between the CE and PE devices, and with virtual routing and forwarding (VRF) configuration.

Not supported.

Not supported.

Cisco 7600 Series Router LFI Restrictions

When configuring LFI on the Cisco 7600 series router, consider the following restrictions:

Frame Relay Fragmentation (FRF.12)

Frame Relay Fragmentation (FRF.12) supports voice and other real-time delay-sensitive data on low-speed links. The standard accommodates variations in frame sizes that allows a combination of real-time and non real-time data.

FRF.12 is developed to allow long data frames to be fragmented into smaller pieces (fragments) and interleaved with real-time frames. In this way, real-time and non-real-time data frames are carried together on lower-speed links without causing excessive delay to the real-time traffic.

Table 5-5 shows the list of SPAs supporting FRF.12 on SIP-400. The table also lists the fragment size and fragment mode.

Table 5-5 List of SPAs supporting FRF.12 on SIP-400

SPA Name
Fragment Size Supported (bytes)
Fragment Mode

1-port Channelized OC12/STM-4 SPA

128, 256, and 512

Hardware

8-Port Channelized T1/E1 SPA

128, 256, and 512

Hardware

2-Port and 4-Port Channelized T3 SPA

128, 256, and 512

Hardware

1-Port Channelized OC-3/STM-1 SPA

128, 256, and 512

Hardware

1-Port Channelizes OC48/DS3 SPA

128, 256, and 512

Hardware

Restrictions

Following restrictions apply for FRF.12 on SIP-400:

  • FRF.12 supports SPA with fragmentation and re-assembly capability in their hardware.
  • Fragmentation support is available only for fragment size of 128, 256 and 512 bytes. Any other value configured is rounded off to the nearest lower denomination from the allowed fragment size with a console message.
  • Fragmentation statistics counters are not supported for SPA based fragmentation.

Configuring FRF.12 on SIP-400

Configure FRF.12 on SIP-400 through Policy-map-class

Complete the following to configure FRF.12 on SIP-400 through policy-map-class.

SUMMARY STEPS


Step 1 enable

Step 2 configure terminal

Step 3 class-map class-map-name

Step 4 match ip precedence precedence-range

Step 5 policy-map policy-map-name

Step 6 class class-name

Step 7 priority percent { x% | y ms }

Step 8 map-class frame-relay map-class-name

Step 9 frame-relay fragment fragment_size

Step 10 service-policy input | output policy-map-name

Step 11 interface serial slot/subslot/port:channel-group

Step 12 ip address address mask

Step 13 encapsulation frame-relay

Step 14 frame-relay interface-type dce | dte

Step 15 frame-relay interface-dlci dlci-number

Step 16 class frf12

Step 17 exit

DETAILED STEPS
Configuration Example

Command or Action
Purpose

Step 1

enable

 

Router> enable

Enables privileged EXEC mode. Enter your password when prompted.

Step 2

configure terminal

 

Router# configure terminal

Enters global configuration mode.

Step 3

class-map [match-all | match-any] class-name

 

Router(config)# class-map match-all prec4

Creates a traffic class.

  • match-all —(Optional) Specifies that all match criteria in the class map must be matched, using a logical function AND of all matching statements defined under the class. This is the default keyword.
  • match-any —(Optional) Specifies that one or more match criteria must match, using a logical function OR of all matching statements defined under the class.
  • class-name —Specifies the user-defined name of the class.

NoteYou can define up to 256 unique class maps.


Step 4

match ip precedence precedence-range

 

Router(config-cmap)# match ip precedence 4

Matches the precedence value in the IP header.

  • precedence-range: Specifies the precedence value ranging from 0 to 7.

Step 5

policy-map policy-map-name

 

Router(config-cmap)# policy-map child2

Specifies the name of the policy map to be created or modified.

  • policy-map-name —Specifies the name of the policy to configure.

Step 6

class class-name

 

Router(config-pmap)# class prec4

Specifies the name of a predefined class included in the service policy.

  • class-name —Specifies the name of the class to configure.

Step 7

priority percent x% | y ms

 

Router(config-pmap-c)# priority percent 45

Enables conditional policing rate (kbps or link percent). Conditional policing is used if the logical or physical link is congested, where:

  • x —Specifies the burst size in kbps.The burst size configures the network to accommodate temporary bursts of traffic.
  • y —Specifies the burst size in bytes.
  • ms —Specifies the burst size in bytes.

Step 8

map-class frame-relay map-class-name

 

Router(config-pmap-c)# map-class frame-relay frf12

Specifies a map class to define FRF.12.

Step 9

frame-relay fragment fragment_size

 

Router(config-map-class)# frame-relay fragment 128

Enables fragmentation of frame relay frames for a frame relay map class.

Step 10

service-policy input | output policy-map-name

 

Router(config-map-class)# service-policy output parent2

Attaches a traffic policy to the input or output direction of an interface, where:

  • policy-map-name —Specifies the name of the traffic policy to configure.

Step 11

interface serial slot/subslot/port:channel-group

 

Router(config-map-class)# interface serial 3/0/2/1:0

Selects the interface to configure.

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

Step 12

ip address ip-address mask

 

Router(config-if)# ip address 111.10.10.11 255.255.255.0

Sets an IP address for an interface.

  • ip-address —IP address.
  • mask —Mask for the associated subnet.

Step 13

encapsulation frame-relay

 

Router(config-if)# encapsulation frame-relay

Enables frame relay encapsulation and allows frame relay processing on the supported interface.

Step 14

frame-relay interface-type dce | dte

 

Router(config-if)# frame-relay interface-type dte

Configures the router to function as a Digital Communications Equipment (DCE) or Data Terminal Equipment (DTE) device.

Step 15

frame-relay interface-dlci dlci-number

 

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

Creates the specified DLCI on the subinterface and enters DLCI configuration mode, where:

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

Step 16

class frf12

no class frf12

 

Router(config-fr-dlci)# class frf12

 

Router(config-fr-dlci)# no class frf12

Specifies a class to define FRF.12.

Use the no form of this command to disable frame relay fragmentation.

Step 17

exit

 

Router(config-fr-dlci)# exit

Returns the command-line interface (CLI) to privileged EXEC mode.

This is an example to configure FRF.12 on SIP-400 through policy-map-class.

Router> enable
Router# configure terminal
Router(config)# class-map match-all precedence 4
Router(config-cmap)# match ip precedence 4
Router(config-cmap)# policy-map child2
Router(config-pmap)# class precedence 4
Router(config-pmap-c)# priority percent 45
Router(config-pmap-c)# map-class frame-relay frf12
Router(config-map-class)# frame-relay fragment 128
Router(config-map-class)# service-policy output parent2
Router(config-map-class)# interface serial 3/0/2/1:0
Router(config-if)# ip address 111.10.10.11 255.255.255.0
Router(config-if)# encapsulation frame-relay
Router(config-if)# frame-relay intf-type dte
Router(config-if)# frame-relay interface-dlci 100
Router(config-fr-dlci)# class frf12
Router(config-fr-dlci)# exit

 

This is an example to disable FRF.12 on SIP-400 through policy-map-class:

Router(config-map-class)# interface Serial3/0/2/1:0
Router(config-if)# frame-relay interface-dlci 100
Router(config-fr-dlci)# no class frf12

Configure End-to-end FRF.12 Fragmentation on SIP-400

Complete the following to configure end-to-end FRF.12 fragmentation on SIP-400.

SUMMARY STEPS


Step 1 enable

Step 2 configure terminal

Step 3 interface serial slot/subslot/port:channel-group

Step 4 ip address address mask

Step 5 encapsulation frame-relay

Step 6 frame-relay interface-dlci dlci-number [protocol ip ip-address ]

Step 7 frame-relay interface-type dce | dte

Step 8 frame-relay fragment fragment_size end-to-end

Step 9 exit

DETAILED STEPS
Configuration Example

Command or Action
Purpose

Step 1

enable

 

Router> enable

Enables privileged EXEC mode.

Enter your password when prompted.

Step 2

configure terminal

 

Router# configure terminal

Enters global configuration mode.

Step 3

interface serial slot/subslot/port:channel-group

 

Router(config-map-class)# interface Serial 3/0/2/1:0

Selects the interface to configure.

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

Step 4

ip address ip-address mask

 

Router(config-if)# ip address 111.10.10.11 255.255.255.0

Sets an IP address for an interface.

  • ip-address —IP address.
  • mask —Mask for the associated subnet.

Step 5

encapsulation frame-relay

 

Router(config-if)# encapsulation frame-relay

Enables frame relay encapsulation and allows frame relay processing on the supported interface.

Step 6

frame-relay interface-dlci dlci-number [protocol ip ip-address ]

 

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

For point-to-point subinterfaces, assigns a data link connection identifier (DLCI) to the interface that connects to the new router, and provides the IP address of the serial port on the new router. This command should be used if the staging router is acting as the BOOTP server.

Step 7

frame-relay interface-type dce | dte

 

Router(config-if)# frame-relay interface-type dte

Configures the router to function as a Digital Communications Equipment (DCE) or Data Terminal Equipment (DTE) device.

Step 8

frame-relay fragment fragment_size end-to-end

no frame-relay fragment fragment_size end-to-end

 

Router(config-if)# frame-relay fragment 128 end-to-end

 

Router(config-if)# no frame-relay fragment 128 end-to-end

Enables fragmentation of frame relay frames on an interface.

Use the no form of this command to disable frame relay fragmentation.

Step 9

exit

 

Router(config-if)# exit

Returns the command-line interface (CLI) to privileged EXEC mode.

This is an example to configure FRF.12 on SIP-400 through policy-map-class.

Router> enable
Router# configure terminal
Router(config)# interface Serial3/0/2/1:0
Router(config-if)# ip address 111.10.10.11 255.255.255.0
Router(config-if)# encapsulation frame-relay
Router(config-if)# frame-relay interface-dlci 100
Router(config-if)# frame-relay intf-type dte
Router(config-if)# frame-relay fragment 128 end-to-end
Router(config-if)# exit

Verifying the Configuration

This section provides the commands to verify the configuration of FRF.12 on SIP-400.

Router# show frame-relay fragment
interface dlci frag-type size in-frag out-frag dropped-frag
Se3/0/2/1:0.1 *** fragment counters are not supported ***

Note The show frame-relay fragment command does not work for hardware based fragmentation.


Router# show frame-relay pvc
 
PVC Statistics for interface Serial3/0/2/1:0 (Frame Relay DCE)
 
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
 
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0/2/1:0.1
 
input pkts 20 output pkts 17 in bytes 7640
out bytes 5799 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 16 out bcast bytes 5760
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:19:08, last time pvc status changed 00:09:22
fragment type end-to-end fragment size 128 <<<<<<<<<

Troubleshooting Tips

Problem
Solution

How do I debug the NPC frame relay.

Use the debug npc frame-relay command to display information related to Frame Relay fragmentation on an NPC. Use the command on LC.

How do I display the contents of the next hop protocol address to DLCI mapping table on the router.

Use the show frame-relay map command. Sample output of the command:

Router# show frame-relay map
Serial1/2 (up): ip 172.16.1.4 dlci 401(0x191,0x6410), dynamic,
broadcast,, status defined, active
Serial1/2 (up): ip 172.16.1.5 dlci 501(0x1F5,0x7C50), dynamic,
broadcast,, status defined, active
Serial1/2 (up): ip 172.16.1.2 dlci 301(0x12D,0x48D0), dynamic,
broadcast,, status defined, active

Configuring Voice over Frame Relay FRF.11 and FRF.12

Voice over Frame Relay (VoFR) enables a router to carry voice traffic (for example, telephone calls and faxes) over a frame relay network using the FRF.11 protocol. This specification defines multiplexed data, voice, fax, dual-tone multi-frequency (DTMF) digit-relay, and channel-associated signaling (CAS) frame formats. The Frame Relay backbone must be configured to include the map class and Local Management Interface (LMI).

The Cisco VoFR implementation enables dynamic- and tandem-switched calls and Cisco trunk calls. Dynamic-switched calls include dial-plan information included that processes and routes calls based on the telephone numbers. The dial-plan information is contained within dial-peer entries.


NoteBecause the Cisco 7600 series router does not support voice modules, it can act only as a VoFR tandem switch when FRF.11 or FRF.12 is configured on the SIPs.


Tandem-switched calls are switched from incoming VoFR to an outgoing VoFR-enabled data-link connection identifier (DLCI) and tandem nodes enable the process. The nodes also switch Cisco trunk calls.

Permanent calls are processed over the Cisco private-line trunks and static FRF.11 trunks that specify the frame format and coder types for voice traffic over a Frame Relay network.

VoFR connections depend on the hardware platform and type of call. The types of calls are:

  • Switched (user dialed or auto-ringdown and tandem)
  • Permanent (Cisco trunk or static FRF.11 trunk)

NoteFRF.11 support was removed in Cisco IOS Release 12.2(18)SXF on the Cisco 7600 series router.


Table 5-6 provides information about where the VoFR feature for SPA interfaces is supported.

 

Table 5-6 VoFR Feature Compatibility by SIP and SPA Combination

Feature
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

FRF.11

In Cisco IOS Releases 12.2(18)SXE and 12.2(18)SXE2:

  • 8-Port Channelized T1/E1 SPA
  • 2-Port and 4-Port Channelized T3 SPA

Not supported

Not supported

FRF.12

In Cisco IOS Release 12.2(18)SXE and later, and in Cisco IOS Release 12.2(33)SRA for FRF.12 in SPA, which is hardware mode:

  • 8-Port Channelized T1/E1 SPA
  • 2-Port and 4-Port Channelized T3 SPA
  • 1-Port Channelized OC-3/STM-1 SPA

In Cisco IOS Release 12.2(18)SXE and later, and in Cisco IOS Release 12.2(33)SRA for FRF.12 in LC mode, which is software mode:

  • SPA-12in1
  • SPA-2xt3/e3
  • SPA-4xt3/e3

Supported

Not supported

FRF.12

Effective with 15.2(1)S Release, FRF.12 supports SIP-400 with the following Channelized SPAs:

  • 1-port Channelized OC12/STM4 SPA
  • 8-port Channelized T1/E1 SPA
  • 2-port and 4-port Channelized T3 SPA
  • 1-port Channelized OC3/STM1 SPA
  • 1-port Channelized OC48/STM16/DS3 SPA

Supported

Not supported

For specific information about configuring voice over Frame Relay FRF.11 and FRF.12, refer to the Cisco IOS Voice, Video, and Fax Configuration Guide located at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fvvfax_c/vvfvofr.htm

Configuring Layer 2 Interworking Features on a SIP

This section provides SIP-specific information about configuring the Layer 2 interworking features on the Cisco 7600 series router. It includes the following topics:

Configuring Bridging for ATM Interfaces (RFC 1483/RFC 2684)

The following types of bridging are supported on ATM SPAs in the Cisco 7600 series router. For information about SIP and SPA compatibility with each of these features, see Table 5-7 .


NoteRFC 1483 has been obsoleted and superseded by RFC 2684,Multiprotocol Encapsulation over ATM Adaptation Layer 5. To avoid confusion, this document continues to refer to the original RFC numbers.


  • RFC 1483/RFC 2684 bridging for point-to-point PVCs —RFC 1483 has been obsoleted and superseded by RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5 . RFC 2684 specifies the implementation of point-to-point bridging of Layer 2 PDUs from an ATM interface.
  • RFC 1483/RFC 2684 bridging with IEEE 802.1Q tunneling—Allows service providers to aggregate multiple VLANs over a single VLAN, while still keeping the individual VLANs segregated and preserving the VLAN IDs for each customer. This tunneling simplifies traffic management for the service provider, while keeping customer networks secure.
  • RFC 1483/RFC 2684 half-bridging—Routes IP traffic from a stub-bridged Ethernet LAN over a bridged RFC 1483/RFC 2684 ATM interface, without using integrated routing and bridging (IRB). This allows bridged traffic that terminates on an ATM PVC to be routed on the basis of the destination IP address.
  • ATM routed bridge encapsulation (RBE)—The ATM SPAs support ATM Routed Bridge Encapsulation (RBE), which is similar in functionality to RFC 1483 ATM half-bridging, except that ATM half-bridging is configured on a point-to-multipoint PVC, while RBE is configured on a point-to-point PVC.
  • Bridging of routed encapsulations (BRE)—Enables an ATM SPA to receive RFC 1483/2684 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 forwarding engine to the Layer 2 interface determined by the VLAN number and destination MAC.
  • Per VLAN Spanning Tree (PVST) to PVST+ Bridge Protocol Data Unit (BPDU) interoperability—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, 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) instead of the standard IEEE 802.1D frame format used by PVST. PVST+ BPDUs are also known as Simple Symmetric Transmission Protocol (SSTP) BPDUs.

NoteThe 1GE SPA on SIP-400 does not support the encapsulation dot1q vlan-id [native] command


Table 5-7 provides information about where the bridging features for ATM SPA interfaces are supported. For more details about the implementation and information about configuring bridging for ATM SPA interfaces, see Chapter8, “Configuring the ATM SPAs”

 

Table 5-7 Bridging for ATM Interfaces Feature Compatibility by SIP and SPA Combination

Feature
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

RFC 1483/RFC 2684 Bridging for Point-to-Point PVCs ( bridge-domain command)

In Cisco IOS Release 12.2(18)SXE and later, and in Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA

In Cisco IOS Release 12.2(18)SXE and later, and in Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA
  • 1-Port OC-12c/STM-4 ATM SPA

Not supported.

RFC 1483/RFC 2684 Bridging with IEEE 802.1Q Tunneling for Point-to-Point PVCs ( bridge-domain dot1q-tunnel command)

In Cisco IOS Release 12.2(18)SXE and later, and in Cisco IOS Release 12.2(33)SRA and later:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA

In Cisco IOS Release 12.2(18)SXE and later, and in Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA
  • 1-Port OC-12c/STM-4 ATM SPA

In Cisco IOS Release 12.2(18)SXF and Cisco IOS Release 12.2(33)SRA and later:

  • 1-Port OC-48c/STM-16 ATM SPA

Not supported.

RFC 1483/RFC 2684 Half-Bridging for Point-to-Multipoint PVCs

In Cisco IOS Release 12.2(18)SXE and later, and in Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA

Not supported.

Not supported.

RFC 1483/RFC 2684 Routed Bridge Encapsulation (RBE) for Point-to-Point PVCs

In Cisco IOS Release 12.2(18)SXE and later, and in Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA

Not supported.

Not supported.

RFC 1483/RFC 2684 Bridging of Routed Encapsulations (BRE) for PVCs

In Cisco IOS Release 12.2(18)SXE and later, and in Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA

In Cisco IOS Release 12.2(33)SRD and later:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA

Not supported.

Enhancements to RFC 1483/RFC 2684 Spanning Tree Interoperability (PVST to PVST+ BPDU Interoperability)

In Cisco IOS Release 12.2(18)SXF2 and later, and in Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA

In Cisco IOS Release 12.2(18)SXF2 and later, and in Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA
  • 1-Port OC-12c/STM-4 ATM SPA
  • 1-Port OC-48c/STM-16 ATM SPA

Not supported.

Multi-VLAN to VC

In Cisco IOS Release 12.2(18)SXE and later, and in Cisco IOS Release 12.2(33)SRA and later:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA

In Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA
  • 1-Port OC-12c/STM-4 ATM SPA
  • 1-Port OC-48c/STM-16 ATM SPA

Not supported.

Configuring Multipoint Bridging

Multipoint bridging (MPB) enables the connection of multiple ATM PVCs, Frame Relay PVCs, Bridge Control Protocol (BCP) ports, and WAN Gigabit Ethernet subinterfaces into a single broadcast domain (virtual LAN), together with the LAN ports on that VLAN. This enables 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/RFC 2684 bridging, and Frame Relay interfaces use RFC 1490/RFC 2427 bridging, both of which provide an encapsulation method to allow the transport of Ethernet frames over each type of Layer 2 network.

Beginning in Cisco IOS Release 12.2(33)SRA, MPB support is added on the Cisco 7600 SIP-400 to multiplex different VLANs that are configured across multiple Gigabit Ethernet subinterfaces into a single broadcast domain. Gigabit Ethernet interfaces can also reside on different Cisco 7600 SIP-400s and belong to the same bridge domain.

Table 5-8 provides information about where the MPB features for SPA interfaces are supported.

 

Table 5-8 MPB Feature Compatibility by SIP and SPA Combination

Feature
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

MPB—60 VCs or interfaces per VLAN globally in system

In Cisco IOS Release 12.2(18)SXE and later:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA
  • 2-Port and 4-Port Channelized T3 SPA
  • 2-Port and 4-Port Clear Channel T3/E3 SPA
  • 8-Port Channelized T1/E1 SPA

In Cisco IOS Release 12.2(18)SXE and later:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA
  • 1-Port OC-12c/STM-4 ATM SPA

Not supported.

MPB—112 VCs or interfaces per VLAN on each SIP

Note If you are using Virtual Private LAN Service (VPLS), see the MPB configuration guidelines.

In Cisco IOS Release 12.2(33)SRA:

  • 1-Port Channelized OC-3/STM-1 SPA
  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA
  • 2-Port and 4-Port OC-3c/STM-1 POS SPA
  • 2-Port and 4-Port Channelized T3 SPA
  • 2-Port and 4-Port Clear Channel T3/E3 SPA
  • 8-Port Channelized T1/E1 SPA

Not applicable.

Not supported.

MPB—120 VCs or interfaces per VLAN on each SIP

Note If you are using VPLS, see the MPB bridging configuration guidelines.

Not supported.

In Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port OC-3c/STM-1 ATM SPA
  • 1-Port OC-12c/STM-4 ATM SPA
  • 1-Port OC-48c/STM-16 ATM SPA
  • 2-Port and 4-Port OC-3c/STM-1 POS SPA
  • 1-Port OC-12c/STM-4 POS SPA
  • 1-Port OC-48c/STM-16 POS SPA

In Cisco IOS Release 15.2(1)S:

  • 1-Port Channelized OC12/STM-4 SPA
  • 2-Port and 4-Port T3/E3 SPA
  • 8-Port Channelized T1/E1 SPA
  • 1-Port Channelized OC-3/STM-1 SPA
  • 1-Port Channelized OC48/STM/16/DS3 SPA
  • 2 and 4-Port Clear Channel T3/E3 SPA

Not supported.

MPB on Gigabit Ethernet—Layer 2 bridging of frames between subinterfaces on different physical Gigabit Ethernet ports

Not supported.

In Cisco IOS Release 12.2(33)SRA:

  • 2-Port Gigabit Ethernet SPA

Not supported.

PIM snooping for MPB

Not supported.

Supported for all SPAs in Cisco IOS Release 12.2(33)SRA.

Not supported.

Configuring MPB for ATM PVCs

You can configure MPB manually on individual PVCs, or you can configure a range of PVCs to configure all of the PVCs at one time. ATM interfaces use RFC 1483/RFC 2684 bridging, which provides an encapsulation method to allow the transport of Ethernet frames over the Layer 2 network.


NoteRFC 1483 has been obsoleted and superseded by RFC 2684,Multiprotocol Encapsulation over ATM Adaptation Layer 5. To avoid confusion, this document continues to refer to the original RFC numbers.


MPB for ATM PVCs Configuration Guidelines

  • Only ATM permanent virtual circuits (PVCs) are supported. SVCs are not supported.
  • MPB is not supported on VLAN IDs 0, 1, 1002–1005, and 4095.
  • Refer to Table 5-8 for limitations on the number of supported VCs.
  • If you are using VPLS on a VC, then the total number of supported VC connection points for MPB (112 for the Cisco 7600 SIP-200, or 120 for the Cisco 7600 SIP-400) is reduced by one for each VPLS VC configured on that bridged VLAN. This reduces the total available number of VC connection points for MPB on that VLAN globally for that SIP. For example, if you configure 10 VPLS VCs on bridged VLAN 100, for a SPA on a Cisco 7600 SIP-200 in slot 4, then 10 connection points are allocated to the VPLS VCs for VLAN 100 across the SIP in slot 4. The total number of connection points available for MPB on VLAN 100 for the Cisco 7600 SIP-200 in slot 4 is 112 minus 10, or 102. A different VLAN (for example, VLAN 300) on that same Cisco 7600 SIP-200 in slot 4, without any VPLS VCs, will have the full 112 VCs available.
  • Routing and bridging is supported on the same interface or subinterface, but for security reasons, routing and bridging is not supported on any given PVC. Therefore, you should not configure an IP address on a point-to-point subinterface and then configure bridging on a PVC on that subinterface.
  • For a limited form of trunking on ATM PVCs supporting multiple VLANs to a single VC, you can configure dot1q tag . However, this configuration can lead to a performance penalty. When using this configuration, you can specify up to 32 bridge-domain command entries for a single PVC. The highest tag value in a group of bridge-domain commands must be greater than the first tag entered (but less than 32 greater than the first tag entered).

SUMMARY STEPS


Step 1 vlan vlan-id | vlan-range

Step 2 interface atm slot / subslot / port

Step 3 interface atm slot / subslot / port . subinterface point-to-point | multipoint


NoteAll commands up till here must be executed at the global configutation mode. Herafter the commands will be executed at the sub-interface configuration mode


Step 4 no ip address

Step 5 pvc name vpi | vci
or
range range-name pvc start-vpi | start-vci end-vpi | end-vci

Step 6 bridge-domain vlan-id access | dot1q tag | dot1q-tunnel ignore-bpdu-pid pvst-tlv CE-vlan increment split-horizon

DETAILED STEPS

To configure MPB for ATM PVCs, perform the following steps beginning in global configuration mode.

 

Command
Purpose

Step 1

Router(config)# vlan vlan-id | vlan-range

Adds the specified VLAN IDs to the VLAN database and enters VLAN configuration mode, where:

  • vlan-id—Specifies a single VLAN ID. The valid range is from 2 to 4094.
  • v lan-range—Specifies multiple VLAN IDs, as either a list or a range. The vlan-range can contain a list of the VLAN IDs, separated 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 2

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

Specifies or creates an ATM interface, where:

  • slot —Specifies the chassis slot number where the SIP is installed.
  • subslot —Specifies the secondary slot number on a SIP where a SPA is installed.
  • port —Specifies the number of the interface port on the SPA.

Step 3

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

Specifies or creates a subinterface and enters subinterface configuration mode, where:

  • slot —Specifies the chassis slot number where the SIP is installed.
  • subslot —Specifies the secondary slot number on a SIP where a SPA is installed.
  • port —Specifies the number of the interface port on the SPA.
  • . subinterface —Specifies the number of the subinterface on the interface port.
  • point-to-point —Specifies a point-to-point subinterface.
  • multipoint —Specifies a multipoint subinterface that allows multiple PVCs to use the same subinterface.

Step 4

Router(config-subif)# no ip address

Disables IP processing on the subinterface by removing its IP address.

Use the following commands (pvc and bridge-domain) to create and configure PVCs individually. Repeat these commands as desired. Or, use the range pvc and bridge-domain command with the increment keyword to configure a range of PVCs.

Step 5

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

or

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

Configures a new ATM PVC or range of ATM PVCs with the specified VPI and VCI numbers and enters VC configuration mode or PVC range configuration mode, where:

  • name—(Optional) Specifies the descriptive name to identify this PVC.
  • vpi/vci—Specifies the virtual path identifier (VPI) and virtual channel identifier (VCI) for this PVC.
  • range-name —(Optional) Specifies the descriptive name of the range, up to a maximum of 15 characters.
  • start-vpi / —Specifies the 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 —Specifies the beginning value for a range of virtual channel identifiers (VCIs). The valid range is from 32 to 65535.
  • end-vpi / —Specifies the 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 —Specifies the end value for a range of virtual channel identifiers (VCIs). The VCI value ranges from 32 to 65535.

Step 6

Router(config-if-atm-vc)# bridge-domain vlan-id access | dot1q tag | dot1q-tunnel ignore-bpdu-pid pvst-tlv CE-vlan increment split-horizon

Enables RFC 1483 bridging to map a bridged VLAN to an ATM PVC, where:

  • vlan-id— Specifies the number of the VLAN to be used in this bridging configuration. The valid range is from 2 to 4094. The VLAN ID must have been previously added to the VLAN database in Step 1.
  • access —(Optional) Enables access-only bridging access mode, in which the bridged connection does not transmit or act upon bridge protocol data unit (BPDU) packets.
  • dot1q —(Optional) Enables IEEE 802.1Q tagging to preserve the class of service (CoS) information from the Ethernet frames across the ATM network. If not specified, the ingress side assumes a CoS value of 0 for QoS purposes. Using the dot1q keyword helps avoid misconfiguration because incoming untagged frames, or tagged frames that don’t match the specified vlan-id are dropped.
  • tag —(Optional—ATM PVCs only) Specifies the IEEE 802.1Q value in the range 1 to 4095. You can specify up to 32 bridge-domain command entries using dot1q tag for a single PVC. The highest tag value in a group of bridge-domain commands must be greater than the first tag entered (but less than 32 greater than the first tag entered).
  • dot1q-tunnel —(Optional) Enables IEEE 802.1Q tunneling mode, so that service providers can use a single VLAN to support customers who have multiple VLANs, while preserving customer VLAN IDs and keeping traffic in different customer VLANs segregated.

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 processes and transmits BPDU packets.

  • ignore-bpdu-pid —(Optional—ATM PVCs only) Ignores the protocol-ID field in RFC 1497 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.

 

 

  • pvst-tlv CE-vlan —(Optional) When transmitting, translates PVST+ BPDUs into IEEE BPDUs. When receiving, translates IEEE BPDUs into PVST+ BPDUs. CE-vlan specifies the customer-edge VLAN in the SSTP Tag-Length-Value (TLV) to be inserted in an IEEE BPDU to a PVST+ BPDU conversion.
  • increment —(Optional—PVC range configuration mode only) Increments the bridge domain number for each PVC in the range. This keyword is used when you are configuring a range of PVCs using the range pvc command.
  • split-horizon —(Optional) Drops egress traffic going out a VC or interface with split-horizon configured, that arrived on an interface with split-horizon configured.

Verifying MPB for ATM PVCs

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.

NoteUse 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

 

Verification

Use these commands to verify operation.

 

Command
Purpose

Router# show ethernet service evc [id evc-id | interface interface-id] [detail]

Displays information pertaining to a specific EVC if an EVC ID is specified, or pertaining to all EVCs on an interface if an interface is specified. The detail option provides additional information on the EVC.

Router# show ethernet service instance [id instance-id interface interface-id | interface interface-id] [detail]

Displays information about one or more service instances: If a service instance ID and interface are specified, only data pertaining to that particular service instance is displayed. If only an interface ID is specified, displays data for all service instances on the given interface.

Router# show ethernet service interface [interface-id] [detail]

Displays information in the Port Data Block (PDB).

Router# show ethernet service instance summary

Displays overall EVC count as well as individual interface EVC count.

Configuring MPB for Frame Relay

You can configure MPB for Frame Relay on individual DLCI circuits. You can optionally add 802.1Q tagging or 802.1Q tunneling. Frame Relay interfaces use RFC 1490/RFC 2427 bridging, which provides an encapsulation method to allow the transport of Ethernet frames over the Layer 2 network.


NoteRFC 1490 has been obsoleted and superseded by RFC 2427,Multiprotocol Interconnect over Frame Relay. To avoid confusion, this document continues to refer to the original RFC numbers.


MPB for Frame Relay Configuration Guidelines

  • Multipoint bridging on Frame Relay interfaces supports only IETF encapsulation. Cisco encapsulation is not supported for MPB.
  • MPB is not supported on VLAN IDs 0, 1, 1002–1005, and 4095.
  • Refer to Table 5-8 for limitations on the number of supported VCs.
  • If you are using VPLS, then the total number of supported DLCI connection points for MPB (112 for the Cisco 7600 SIP-200, or 120 for the Cisco 7600 SIP-400) is reduced by one for each VPLS instance configured on that bridged VLAN. This reduces the total available number of DLCI connection points for MPB on that VLAN globally for that SIP. For example, if you configure 10 VPLS instances on a bridged VLAN 100, for a SPA on a Cisco 7600 SIP-200 in slot 4, then 10 connection points are allocated to the VPLS instances for VLAN 100 across the SIP in slot 4. The total number of connection points available for MPB on VLAN 100 for the Cisco 7600 SIP-200 in slot 4 is 112 minus 10, or 102. A different VLAN (for example, VLAN 300) on that same Cisco 7600 SIP-200 in slot 4, without any VPLS DLCIs, will have the full 112 DLCIs available.
  • Routing and bridging is supported on the same interface or subinterface, but for security reasons, routing and bridging is not supported on any given DLCI. Therefore, you should not configure an IP address on a point-to-point subinterface and then configure bridging on a DLCI on that subinterface.

SUMMARY STEPS


Step 1 vlan vlan-id | vlan-range

Step 2 interface serial slot / subslot / port
or
interface pos slot / subslot / port

Step 3 encapsulation frame-relay ietf

Step 4 interface serial slot / subslot / port . subinterface point-to-point | multipoint
OR
interface serial slot / subslot / port / t1-number : channel-group . subinterface point-to-point | multipoint
OR
interface serial slot/ subslot / port : channel-group . subinterface point-to-point | multipoint
OR
interface pos slot / subslot / port . subinterface point-to-point | multipoint

OR

interface serial address


NoteAll commands up till here must be executed at the global configutation mode. Herafter the commands will be executed at the sub-interface configuration mode unless specifically mentioned otherwise


Step 5 no ip address

Step 6 frame-relay interface-dlci dlci ietf

Step 7 bridge-domain vlan-id access | dot1q | dot1q-tunnel pvst-tlv CE-vlan split-horizon (This command is executed on the DLCI interface configuration mode)


NoteChOC-12 does not support the bridge-domain command.


DETAILED STEPS

To configure MPB for Frame Relay on serial or POS SPAs, perform the following steps beginning in global configuration mode:

 

Command
Purpose

Step 1

Router(config)# vlan vlan-id | vlan-range

Adds the specified VLAN IDs to the VLAN database and enters VLAN configuration mode, where:

  • vlan-id—Specifies a single VLAN ID. The valid range is from 2 to 4094.
  • v lan-range—Specifies multiple VLAN IDs, as either a list or a range. The vlan-range can contain a list of the VLAN IDs, separated 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 2

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

or

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

Specifies or creates a serial or POS interface, where:

  • slot —Specifies the chassis slot number where the SIP is installed.
  • subslot —Specifies the secondary slot number on a SIP where a SPA is installed.
  • port —Specifies the number of the interface port on the SPA.

Step 3

Router(config-if) encapsulation frame-relay ietf

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

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

Step 4

2-Port and 4-Port Clear Channel T3/E3 SPA

Router(config)# interface serial slot / subslot / port . subinterface point-to-point | multipoint

2-Port and 4-Port Channelized T3 SPA

Router(config)# interface serial slot / subslot / port / t1-number : channel-group . subinterface point-to-point | multipoint

8-Port Channelized T1/E1 SPA

Router(config)# interface serial slot/ subslot / port : channel-group . subinterface point-to-point | multipoint

1-Port Channelized OC-3/STM-1 SPA and 1-Port Channelized OC-12/STM-4 SPA

Router(config)# interface serial address

1-Port OC-12c/STM-4 POS SPA or 2-Port and 4-Port OC-3c/STM-1 POS SPA

Router(config)# interface pos slot / subslot / port . subinterface point-to-point | multipoint

Specifies or creates a subinterface and enters subinterface configuration mode, where:

  • slot —Specifies the chassis slot number where the SIP is installed.
  • subslot —Specifies the secondary slot number on a SIP where a SPA is installed.
  • port —Specifies the number of the interface port on the SPA.
  • . subinterface —Specifies the number of the subinterface on the interface port.
  • t1-number —Specifies the logical T1 number in channelized mode.
  • address —For the different supported syntax options for the address argument for the 1-Port Channelized OC-3/STM-1 SPA or 1-Port Channelized OC-12/STM-4 SPA, see the “Interface Naming” section of the “Configuring the 1-Port Channelized OC-3/STM-1 SPA” chapter.
  • channel-group—Specifies the logical channel group assigned to the time slots within the T1 or E1 group.
  • point-to-point —Specifies a point-to-point subinterface.
  • multipoint—Allows multiple PVCs to use the same subinterface

Step 5

Router(config-subif)# no ip address

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

Step 6

Router(config-subif)# frame-relay interface-dlci dlci ietf

Creates the specified DLCI on the subinterface and enters DLCI configuration mode, where:

  • dlci—Specifies the 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 4.

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

Step 7

Router(config-fr-dlci)# bridge-domain vlan-id access | dot1q | dot1q-tunnel pvst-tlv CE-vlan split-horizon

Enables RFC 1490 bridging to map a bridged VLAN to a Frame Relay DLCI, where:

  • vlan-id — Specifies the number of the VLAN to be used in this bridging configuration. The valid range is from 2 to 4094. The VLAN ID must have been previously added to the VLAN database in Step 1.
  • access —(Optional) Enables access-only bridging access mode, in which the bridged connection does not transmit or act upon bridge protocol data unit (BPDU) packets.
  • dot1q —(Optional) Enables IEEE 802.1Q tagging to preserve the class of service (CoS) information from the Ethernet frames across the Frame Relay network. If not specified, the ingress side assumes a CoS value of 0 for QoS purposes. Using the dot1q keyword helps avoid misconfiguration because incoming untagged frames, or tagged frames that do not match the specified vlan-id are dropped.
  • dot1q-tunnel —(Optional) Enables IEEE 802.1Q tunneling mode, so that service providers can use a single VLAN to support customers who have multiple VLANs, while preserving customer VLAN IDs and keeping traffic in different customer VLANs segregated.

 

 

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 processes and transmits BPDU packets.

  • pvst-tlv CE-vlan —(Optional) When transmitting, translates PVST+ BPDUs into IEEE BPDUs. When receiving, translates IEEE BPDUs into PVST+ BPDUs. CE-vlan specifies the customer-edge VLAN in the SSTP Tag-Length-Value (TLV) to be inserted in an IEEE BPDU to a PVST+ BPDU conversion.
  • split-horizon —(Optional) Drops egress traffic going out a VC or interface with split-horizon configured, that arrived on an interface with split-horizon configured.

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

 

 

 

Verifying MPB for Frame Relay

To display information about the DLCIs that have been configured on Frame Relay interfaces, use the show frame-relay vlan command.

Router# show frame-relay vlan
Interface Bridge DLCI Domain
POS3/1/0.100 100 100

Configuring MPB for Gigabit Ethernet

Beginning in Cisco IOS Release 12.2(33)SRA, MPB support is added on the Cisco 7600 SIP-400 to multiplex different VLANs that are configured across multiple Gigabit Ethernet subinterfaces into a single broadcast domain. Gigabit Ethernet interfaces can also reside on different Cisco 7600 SIP-400s and belong to the same bridge domain.

MPB for Gigabit Ethernet Configuration Guidelines

  • The Cisco 7600 SIP-400 can support a total of up to 4096 subinterfaces and bridge-domain instances per VLAN. For example, one subinterface with a configured VLAN using MPB will consume two of the available 4096 total allowable subinterfaces and bridge domains combined.
  • Up to 60 subinterfaces can be put into the same bridge domain on the Cisco 7600 SIP-400.

To configure MPB for Gigabit Ethernet, perform the following steps beginning in global configuration mode:

 

Command
Purpose

Step 1

Router(config)# vlan { vlan-id | vlan-range }

Adds the specified VLAN IDs to the VLAN database and enters VLAN configuration mode, where:

  • vlan-id—Specifies a single VLAN ID. The valid range is from 2 to 4094.
  • v lan-range—Specifies multiple VLAN IDs, as either a list or a range. The vlan-range can contain a list of the VLAN IDs, separated 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 2

Router(config)# interface gigabitethernet slot / subslot / port . subinterface

Specifies or creates a Gigabit Ethernet subinterface and enters subinterface configuration mode, where:

  • slot —Specifies the chassis slot number where the SIP is installed.
  • subslot —Specifies the secondary slot number on a SIP where a SPA is installed.
  • port —Specifies the number of the interface port on the SPA.
  • . subinterface —Specifies the number of the subinterface on the interface port.

Step 3

Router(config-subif) encapsulation dot1q vlan-id

Enables IEEE 802.1Q encapsulation on the interface, where vlan-id specifies the virtual LAN identifier. The allowed range is from 1 to 4095.

Step 4

Router(config-subif)# bridge-domain vlan-id [ dot1q | dot1q-tunnel ] [ bpdu { drop | transparent }] [ split-horizon ]

Enables bridging of VLANs across Gigabit Ethernet subinterfaces, where:

  • vlan-id — Specifies the number of the VLAN to be used in this bridging configuration. The valid range is from 2 to 4094. The VLAN ID must have been previously added to the VLAN database in Step 1.
  • dot1q —(Optional) Enables IEEE 802.1Q tagging to preserve the class of service (CoS) information from the Ethernet frames across the ATM network. If not specified, the ingress side assumes a CoS value of 0 for QoS purposes.
  • dot1q-tunnel —(Optional) Enables IEEE 802.1Q tunneling mode, so that service providers can use a single VLAN to support customers who have multiple VLANs, while preserving customer VLAN IDs and keeping traffic in different customer VLANs segregated.

Note The dot1q and dot1q-tunnel options are mutually exclusive. If you do not specify either of these options, the connection operates in “raw” bridging access mode, which is similar to access, except that the connection processes and transmits BPDU packets.

  • bpdu { drop | transparent } (Optional) Specifies whether or not BPDUs are processed or dropped, where:

drop —Specifies BPDU packets are dropped on the subinterface.

transparent —Specifies BPDU packets are forwarded as data on the subinterface, but not processed.

  • split-horizon —(Optional) Drops egress traffic going out a VC or interface with split-horizon configured, that arrived on an interface with split-horizon configured.

Configuring Private Hosts SVI (Interface VLAN)

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

Port classification

  • Isolated ports: The hosts which need to be isolated will be directly or indirectly connected through DSLAMs to this type of ports. The unicast traffic received on these ports should be always destined towards specified upstream devices
  • Promiscuous ports: The ports facing the core network or devices like BRAS and multicast servers are called promiscuous ports. These ports can allow any unicast or broadcast traffic received from upstream devices.

Private hosts traffic is treated as Layer 2 traffic and routing needs an external router to be configured. Instead of configuring a server MAC address into Private Hosts, you must configure the router MAC address. This featureadds the SVIs into the Private Host configuration, eliminating the need for the external router

Configuration tasks

To configure the private hosts SVI (Interface VLAN) feature, perform the following steps in the global configuration mode:

 

Command
Purpose

Step 1

Router(config)# [no] private-hosts

This command is used enable or disable private hosts feature on a Cisco 7600 device globally. A [no] form of the command disables the private hosts feature globally.

This command is in disabled mode by default

Step 2

Router(config)# [no] private-hosts mac-list <mac-list name> <mac address >

This command is used to populate the MAC address list. A [no] form of the command is used to delete MAC address from the list. The list itself is deleted after the deletion of last MAC address

Step 3

Router(config)# [no] private-hosts vlan-list <VLAN-ID>

This command is used to provide list of VLANs that need to be isolated. A [no] form will remove the given VLANs from the isolated VLAN list.

Note This VLAN -list is also used to program the promiscuous devices' MAC addresses

Step 4

Router(config)# [no] private-hosts promiscous <mac-list name> [vlan-list <VLAN IDs>]

This command is used to provide list of promiscuous MAC addresses and optional VLAN-list on which these devices might exist.

If the VLAN-list is not given, the VLAN list is taken from the global isolated VLAN- list configured. This command can be executed multiple times with different MAC-list and vlan-list combination

Restrictions

The following restrictions should be considered while configuring the private hosts SVI feature:

  • You cannot restrict Private Host SVIs to a configured subset of VLANs. If you want a subset of VLANs to use SVI's, you must ensure there are no SVIs on the VLANs that are not to be routed.
  • This feature is applicable only to native system.
  • 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 like RACLs do not work with it.
  • This feature is supported only PFC-3BXL or above cards.
  • This feature is not supported on EARL6 or below.

Sample Configuration

PE18_C7606#conf t

Enter configuration commands, one per line. End with CNTL/Z.

PE18_C7606(config)#private-hosts

PE18_C7606(config)#private-hosts mac-list ML1 10de.aa0d.e2ad

PE18_C7606(config)#private-hosts vlan-list?

vlan-list

PE18_C7606(config)#private-hosts vlan-list 1

PE18_C7606(config)#private-hosts promiscuous?

promiscuous

PE18_C7606(config)#private-hosts promiscuous ML1

Verifying the Private Hosts SVI (Interface VLAN) configuration

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

Command
Purpose

Router(config)# show private-hosts configuration

Displays the global private hosts configuration

Router(config)# show private-hosts access-lists

Displays the private hosts related access lists

Router(config)# show private-hosts interface configuration

Displays the ports on which the feature is enabled with the configured mode

Router(config)# show private-hosts mac-list

Displays the configured mac-lists and their members

Configuring Private Hosts over Virtual Private LAN Service (VPLS)

The private host feature supports the redirection of broadcast and unicast from isolated ports over VPLS virtual circuit. The private host feature allows the addition of one VPLS enabled VLAN (cross-connect configured on a VLAN) in the private host vlan-list, along with the regular VLAN and SVI.

Restrictions and Guidelines

While configuring private hosts over VPLS, besides noting the private host SVI restrictions listed in Restrictions, keep the following additional guidelines in mind:

  • Private host limits VPLS support for only one VLAN. If the private host Vlan-list already has a VPLS VLAN (VLAN with cross-connect), the addtion of another VPLS VLAN will be blocked.
  • If any VLAN in the Vlan-list has cross-connect configured, configuring cross-connect on another VLAN in the Vlan-list will be blocked.

Configuration Steps

Use the following commands to configure private hosts over VPLS.

SUMMARY STEPS

1. [no] private-hosts

2. private-hosts vlan-list vlan-ids

3. private-hosts promiscuous mac list name

4. private-hosts mac-list mac list name mac-id

DETAILED STEPS

Command
Purpose

Router(config)#[no] private-hosts

Example:

PE17_C7606(config)#private-hosts

Globally enables or disables the Private Hosts SVI feature on a Cisco 7600 device. The ‘no’ form of the command disables this feature globally. By default, this command is in disabled mode.

Router(config)#private-hosts vlan-list vlan-ids

Example:

PE17_C7606(config)#private-hosts vlan-list 10-15

Enables private hosts on the specified VLAN or range of VLAN IDs.

Router(config)#private-hosts promiscuous mac list name

Example:

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

Sets a name for a group of private hosts enabled with promiscuous MAC addresses.

Router(config)#private-hosts mac-list mac list name mac-id

Example:

PE17_C7606(config)#private-hosts mac-list maclist-1 0000.1e11.00d1

Assigns MAC addresses to the MAC list.

Verifying the Private Hosts on the VPLS Configuration

Use the following show commands to verify the private hosts over VPLS configuration:

Command
Purpose

Router(config)# show private-hosts access-lists

Displays access lists related to private hosts

Router(config)#show private-hosts configuration

Displays private hosts global configuration

Router(config)# show private-hosts interface

Displays configuation related to private hosts interface.

Router(config)# show private-hosts mac-list

Displays MAC lists and their members.

Example

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

 

Table 5-9 provides the troubleshooting solutions for the Private Host feature.

Table 5-9 Troubleshooting Scenarios for Private Host feature

Problem
Solution

To troubleshoot and view all the TCAM entries.

Use the sh hw-mod su subslot tcam command to verify and troubleshoot issues related to the TCAM entries.

To troubleshoot and view virtual VLAN IDs on a qinq subinterface.

Use the test hw-mod su subslot command to troubleshoot issues related to virtual VLAN ID values on a QnQ subinterface.

Incorrect VLAN ID is programmed.

Use the command show hw-module subslot tcam all_entries vlan to confirm the correct VLAN IDs.

Erroneous or disabled TCAM entries

Use the show plat soft qos tcamfeature and show platform software qos tcam commands to correct the TCAM entries.

Configuring PPP Bridging Control Protocol Support

The Bridging Control Protocol (BCP) feature on the SIPs and SPAs enables forwarding of Ethernet frames over serial and SONET networks, and provides a high-speed extension of enterprise LAN backbone traffic through a metropolitan area. The implementation of BCP on the SPAs includes support for IEEE 802.1D Spanning Tree Protocol, IEEE 802.1Q Virtual LAN (VLAN), and high-speed switched LANs.

The Bridging Control Protocol (BCP) feature provides support for BCP to Cisco devices, as described in RFC 3518, Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP) . 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.

BCP operates in two different modes:

  • Trunk mode BCP ( switchport )—A single BCP link can carry multiple VLANs.
  • Single-VLAN BCP ( bridge-domain )—A single BCP link carries only one VLAN.

In addition, in Cisco IOS Release 12.2(33)SRA, BCP is supported over dMLPPP links on the Cisco 7600 SIP-200 with the 2-Port and 4-Port Channelized T3 SPA and 8-Port Channelized T1/E1 SPA. BCP over dMLPPP is supported in trunk mode only.

Effective from Cisco IOS release 15.2(1)S, BCP over dMLPPP is also supported on the Cisco 7600 SIP 400 with the following the following SPAs:

  • 2-Port and 4-Port Channelized T3 SPA
  • 8-Port Channelized T1/E1 SPA
  • 1-Port Channelized OC12/STM-4 SPA
  • 1-Port Channelized OC-3/STM-1 SPA
  • 1-Port Channelized OC48/STM/16/DS3 SPA
  • 2 and 4-Port Clear Channel T3/E3 SPA

BCP Feature Compatibility

Table 5-10 provides information about where the BCP features are supported.

 

Table 5-10 BCP Feature Compatibility by SIP and SPA Combination

Feature
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

Trunk mode BCP ( switchport )

In Cisco IOS Release 12.2(18)SXE and later:

  • 2-Port and 4-Port Channelized T3 SPA
  • 2-Port and 4-Port Clear Channel T3/E3 SPA
  • 8-Port Channelized T1/E1 SPA
  • 2-Port and 4-Port OC-3c/STM-1 POS SPA

Support for the following SPA was added in Cisco IOS Release 12.2(33)SRA:

  • 1-Port Channelized OC-3/STM-1 SPA

In Cisco IOS Release 12.2(18)SXE and later:

  • 1-Port OC-12c/STM-4 POS SPA
  • 2-Port and 4-Port OC-3c/STM-1 POS SPA
  • 1-Port OC-48c/STM-16 POS SPA

In Cisco IOS release 15.2(1)S:

  • 1-Port Channelized OC12/STM-4 SPA
  • 2-Port and 4-Port T3/E3 SPA
  • 8-Port Channelized T1/E1 SPA
  • 1-Port Channelized OC-3/STM-1 SPA
  • 1-Port Channelized OC48/STM/16/DS3 SPA
  • 2 and 4-Port Clear Channel T3/E3 SPA

Not supported.

 

 

 

 

Tag-native Mode for Trunk BCP ( switchport )

  • In Cisco IOS 12.2SX releases—Not supported.
  • In Cisco IOS Release 12.2(33)SRA:

2-Port and 4-Port Channelized T3 SPA

2-Port and 4-Port Clear Channel T3/E3 SPA

8-Port Channelized T1/E1 SPA

2-Port and 4-Port OC-3c/STM-1 POS SPA

1-Port Channelized OC-3/STM-1 SPA

  • In Cisco IOS 12.2SX releases—Not supported.
  • In Cisco IOS Release 12.2(33)SRA:

1-Port OC-12c/STM-4 POS SPA

2-Port and 4-Port OC-3c/STM-1 POS SPA

1-Port OC-48c/STM-16 POS SPA

  • In Cisco IOS release 15.2(1)S:

1-Port Channelized OC12/STM-4 SPA

2-Port and 4-Port Channelized T3 SPA

8-Port Channelized T1/E1 SPA

1-Port Channelized OC-3/STM-1 SPA

1-Port Channelized OC48/STM/16/DS3 SPA

2 and 4-Port Clear Channel T3/E3 SPA

Not supported.

Single-VLAN BCP ( bridge-domain )

In Cisco IOS Release 12.2(18)SXE and later:

  • 2-Port and 4-Port Channelized T3 SPA
  • 2-Port and 4-Port Clear Channel T3/E3 SPA
  • 8-Port Channelized T1/E1 SPA
  • 2-Port and 4-Port OC-3c/STM-1 POS SPA

Support for the following SPA was added in In Cisco IOS Release 12.2(33)SRA:

  • 1-Port Channelized OC-3/STM-1 SPA

In Cisco IOS Release 12.2(33)SRA:

  • 1-Port OC-12c/STM-4 POS SPA
  • 2-Port and 4-Port OC-3c/STM-1 POS SPA
  • 1-Port OC-48c/STM-16 POS SPA

In Cisco IOS release 15.2(1)S:

  • 1-Port Channelized OC12/STM-4 SPA
  • 2-Port and 4-Port Channelized T3 SPA
  • 8-Port Channelized T1/E1 SPA
  • 1-Port Channelized OC-3/STM-1 SPA
  • 1-Port Channelized OC48/STM/16/DS3 SPA
  • 2 and 4-Port Clear Channel T3/E3 SPA

Not supported.

BCP over dMLPPP (trunk mode only)

In Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port Channelized T3 SPA
  • 8-Port Channelized T1/E1 SPA

In Cisco IOS release 15.2(1)S:

  • 1-Port Channelized OC12/STM-4 SPA
  • 2-Port and 4-Port Channelized T3 SPA
  • 8-Port Channelized T1/E1 SPA
  • 1-Port Channelized OC-3/STM-1 SPA
  • 1-Port Channelized OC48/STM/16/DS3 SPA

Not supported.

BCP Configuration Guidelines

When configuring BCP support for SPAs on the Cisco 7600 SIP-200 and Cisco 7600 SIP-400, consider the following guidelines:

  • Be sure to refer to Table 5-10 for feature compatibility information.
  • Beginning in Cisco IOS Release 12.2(33)SRA, QoS is supported on bridged interfaces. In Cisco IOS Release 12.2(18)SXF2 and earlier, QoS is not supported on bridged interfaces.
  • Although RFC 3518 specifies support for Token Ring and Fiber Distributed Data Interface (FDDI), BCP on the Cisco 7600 SIP-200 and Cisco 7600 SIP-400 supports only Ethernet currently.

Configuring BCP in Trunk Mode

When BCP is configured in trunk mode, a single BCP link can carry multiple VLANs. This usage of BCP is consistent with that of normal Ethernet trunk ports.

Trunk Mode BCP Configuration Guidelines

When configuring BCP support in trunk mode for SPAs on the Cisco 7600 SIP-200 and Cisco 7600 SIP-400, consider the following guidelines:

  • Be sure to refer to Table 5-10 for feature compatibility information.
  • 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 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.
  • The SIPs support the following maximum number of BCP ports on any given VLAN:

In Cisco IOS Release 12.2(18)SXE and later—Maximum of 60 BCP ports

In Cisco IOS Release 12.2(33)SRA—Maximum of 112 BCP ports on Cisco 7600 SIP-200 and maximum of 120 BCP ports on Cisco 7600 SIP-400.

  • To use VLANs in trunk mode BCP, you must use the vlan command to manually add the VLANs to the VLAN database. The default behavior for trunk mode BCP allows no VLANs.
  • Trunk mode BCP is not supported on VLAN IDs 0, 1006–1023, and 1025.
  • The native VLAN (VLAN1) has the following restrictions for trunk mode BCP:

In Cisco IOS Release 12.2SX—The native VLAN is not supported.

Beginning in Cisco IOS Release 12.2(33)SRA—The native VLAN is supported.

  • For trunk mode BCP (switchport), STP interoperability is the same as that of Ethernet switchports. This means that the STP path cost of WAN links can be changed and other STP functionality such as BPDU Guard and PortFast will work on the WAN links. However, it is not recommended to 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.


To configure BCP in trunk mode, perform the following steps beginning in global configuration mode:

 

Command
Purpose

Step 1

Router(config)# vlan dot1q tag native

(Optional) Enables dot1q tagging for all VLANs in a trunk. By default, packets on the native VLAN are sent untagged. When you enable dot1q tagging, packets are tagged with the native VLAN ID.

Step 2

1-Port Channelized OC-3/STM-1 SPA or 1-Port Channelized OC-12/STM-4 SPA

Router(config)# interface serial address

2-Port and 4-Port Clear Channel T3/E3 SPA

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

2-Port and 4-Port Channelized T3 SPA

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

8-Port Channelized T1/E1 SPA

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

1-Port OC-12c/STM-4 POS SPA or 2-Port and 4-Port OC-3c/STM-1 POS SPA

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

Specifies an interface and enters interface configuration mode, where:

  • address —For the different supported syntax options for the address argument for the 1-Port Channelized OC-3/STM-1 SPA, refer to the “Interface Naming” section of the “Configuring the 1-Port Channelized OC-3/STM-1 SPA” chapter.
  • slot —Specifies the chassis slot number where the SIP is installed.
  • subslot —Specifies the secondary slot number on a SIP where a SPA is installed.
  • port —Specifies the number of the interface port on the SPA.
  • t1-number —Specifies the logical T1 number in channelized mode.
  • channel-group—Specifies the logical channel group assigned to the time slots within the T1 or E1 group.

Step 3

Router(config-if)# switchport

Puts an interface that is in Layer 3 mode into Layer 2 mode for Layer 2 configuration. PPP encapsulation is automatically configured, and the interface is automatically configured for trunk mode and nonegotiate status.

Step 4

Router(config-if)# shutdown

Disables the interface.

Step 5

Router(config-if)# no shutdown

Restarts the disabled interface.

Step 6

Router(config-if)# switchport trunk allowed vlan { all | { add | remove | except } vlan-list [ , vlan-list... ] | vlan-list [ , vlan-list... ]}

(Optional) Controls which VLANs can receive and transmit traffic on the trunk, where:

  • all —Enables all applicable VLANs.
  • add vlan-list [ , vlan-list... ] —Appends the specified list of VLANs to those currently set instead of replacing the list.
  • remove vlan-list [ , vlan-list... ] —Removes the specified list of VLANs from those currently set instead of replacing the list.
  • except vlan-list [ , vlan-list... ] —Excludes the specified list of VLANs from those currently set instead of replacing the list.
  • vlan-list [ , vlan-list... ] Specifies a single VLAN number from 1 to 4094, or a continuous range of VLANs that are described by two VLAN numbers from 1 to 4094. You can specify multiple VLAN numbers or ranges using a comma-separated list.

To specify a range of VLANs, enter the smaller VLAN number first, separated by a hyphen and the larger VLAN number at the end of the range.

Note Do not enable the reserved VLAN range (1006 to 1024) on trunks when connecting a Cisco 7600 series router running the Cisco IOS software on both the supervisor engine and the MSFC to a Cisco 7600 series router running the Catalyst operating system. These VLANs are reserved in Cisco 7600 series routers running the Catalyst operating system. If enabled, Cisco 7600 series routers running the Catalyst operating system may error-disable the ports if there is a trunking channel between these systems.

Note The command no switchport trunk allowed vlan is not supported for BCP interfaces.

Verifying BCP in Trunk Mode

Because the PPP link has to flap (be brought down and renegotiated), it is important that you run the following show commands after you configure BCP in trunk mode to confirm the configuration:

 

Command
Purpose

1-Port Channelized OC-3/STM-1 SPA or 1-Port Channelized OC-12/STM-4 SPA

Router# show interfaces [ serial address ] trunk [module number ]

2-Port and 4-Port Channelized T3 SPA

Router# show interfaces [ serial slot / subslot / port / t1-number : channel-group ] trunk [module number ]

2-Port and 4-Port Clear Channel T3/E3 SPA

Router# show interfaces [ serial slot/ subslot / port ] trunk [module number ]

8-Port Channelized T1/E1 SPA

Router# show interfaces [ serial slot/ subslot / port : channel-group ] trunk [module number ]

1-Port OC-12c/STM-4 POS SPA or 2-Port and 4-Port OC-3c/STM-1 POS SPA

Router# show interfaces [ pos slot / subslot / port ] trunk [module number ]

Displays the interface-trunk information, where:

  • address —For the different supported syntax options for the address argument for the 1-Port Channelized OC-3/STM-1 SPA, refer to the “Interface Naming” section of the “Configuring the 1-Port Channelized OC-3/STM-1 SPA” chapter.
  • slot —Specifies the chassis slot number where the SIP is installed.
  • subslot —Specifies the secondary slot number on a SIP where a SPA is installed.
  • port —Specifies the number of the interface port on the SPA.
  • t1-number —Specifies the logical T1 number in channelized mode.
  • channel-group—Specifies the logical channel group assigned to the time slots within the T1 or E1 group.
  • module number —(Optional) Specifies the chassis slot number of the SIP and displays information for all interfaces of the SPAs in that SIP.

 

The following output of the show interfaces commands provide an example of the information that is displayed when BCP is configured in trunk mode.


NoteWhen switchport is configured, the encapsulation is automatically changed to PPP.


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 interfaces pos4/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

Configuring BCP in Single-VLAN Mode

When BCP is configured in single-VLAN mode, a single BCP link carries only one VLAN. This is considered BCP in access mode.

Single-VLAN Mode BCP Configuration Guidelines

When configuring BCP support in single-VLAN mode for SPAs on the Cisco 7600 SIP-200 and Cisco 7600 SIP-400, consider the following guidelines:

  • Be sure to refer to Table 5-10 for feature compatibility information.
  • Use the bridge-domain vlan-id dot1q form of the command under a WAN interface or an ATM PVC. 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.
  • For serial and POS SPA interfaces, the encapsulation of the interface must be PPP; otherwise, the bridge-domain command will not be accepted.
  • The ATM SPAs on the Cisco 7600 series router do not support single-VLAN BCP.
  • For single-VLAN BCP, you can configure the following maximum number of VCs per VLAN:

In Cisco IOS Release 12.2SX—60 VCs or interfaces per VLAN per chassis.

Beginning in Cisco IOS Release 12.2(33)SRA—112 VCs or interfaces per VLAN per Cisco 7600 SIP-200; 120 VCs or interfaces per VLAN per Cisco 7600 SIP-400.

  • VLANs must be manually added to the VLAN database, using the vlan command, to be able to use those VLANs in single-VLAN BCP.
  • BCP is not supported on VLAN IDs 0, 1 (native), 1006–1023, and 1025.
  • For single-VLAN BCP, only basic Spanning Tree Protocol (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.
  • VLAN Trunking Protocol (VTP) is not supported on single-VLAN BCP.

To configure BCP in single-VLAN mode on serial or POS SPAs, perform the following steps beginning in global configuration mode:

 

Command
Purpose

Step 1

1-Port Channelized OC-3/STM-1 SPA or 1-Port Channelized OC-12/STM-4 SPA

Router(config)# interface serial address

2-Port and 4-Port Channelized T3 SPA

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

8-Port Channelized T1/E1 SPA

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

1-Port OC-12c/STM-4 POS SPA or 2-Port and 4-Port OC-3c/STM-1 POS SPA

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

2-Port and 4-Port Clear Channel T3/E3 SPA

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

Specifies an interface and enters interface configuration mode, where:

  • address —For the different supported syntax options for the address argument for the 1-Port Channelized OC-3/STM-1 SPA, refer to the “Interface Naming” section of the “Configuring the 1-Port Channelized OC-3/STM-1 SPA” chapter.
  • slot —Specifies the chassis slot number where the SIP is installed.
  • subslot —Specifies the secondary slot number on a SIP where a SPA is installed.
  • port —Specifies the number of the interface port on the SPA.
  • t1-number —Specifies the logical T1 number in channelized mode.
  • channel-group—Specifies the logical channel group assigned to the time slots within the T1 or E1 group.

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-id [ dot1q | dot1q-tunnel ]

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

  • vlan-id— Specifies the number of the VLAN to be used in this bridging configuration. The valid range is from 2 to 4094. The VLAN ID must have been previously added to the VLAN database.
  • dot1q —(Optional) Enables IEEE 802.1Q tagging to preserve the class of service (CoS) information from the Ethernet frames across the WAN interface. If not specified, the ingress side assumes a CoS value of 0 for QoS purposes. Using the dot1q keyword helps avoid misconfiguration because incoming untagged frames, or tagged frames that do not match the specified vlan-id are dropped.
  • dot1q-tunnel —(Optional) Enables IEEE 802.1Q tunneling mode, so that service providers can use a single VLAN to support customers who have multiple VLANs, while preserving customer VLAN IDs and keeping traffic in different customer VLANs segregated.

Step 5

Router(config-if)# shutdown

Disables the interface.

Step 6

Router(config-if)# no shutdown

Restarts the disabled interface.

Verifying BCP in Single-VLAN Mode

Because the PPP link has to flap (be brought down and renegotiated), it is important that you run the following show command after you configure BCP in single-VLAN mode to confirm the configuration:

Router# show interfaces pos4/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

Configuring BCP over dMLPPP

Beginning in Cisco IOS Release 12.2(33)SRA, BCP is supported over dMLPPP links on the Cisco 7600 SIP-200 with the 2-Port and 4-Port Channelized T3 SPA and 8-Port Channelized T1/E1 SPA. BCP over dMLPPP is supported in trunk mode only.

Effective from Cisco IOS release 15.2(1)S, BCP over dMLPPP is also supported on the Cisco 7600 SIP 400 with the following the following SPAs:

  • 2-Port and 4-Port Channelized T3 SPA
  • 8-Port Channelized T1/E1 SPA
  • 1-Port Channelized OC12/STM-4 SPA
  • 1-Port Channelized OC-3/STM-1 SPA
  • 1-Port Channelized OC48/STM/16/DS3 SPA

For more information about configuring the BCP over dMLPPP feature, see “Configuring the 8-Port Channelized T1/E1 SPA,” and Chapter19, “Configuring the 2-Port and 4-Port Clear Channel T3/E3 SPAs”

Configuring Virtual Private LAN Service

Virtual Private LAN Service (VPLS) enables geographically separate LAN segments to be interconnected as a single bridged domain over a packet switched network, such as IP, MPLS, or a hybrid of both.

VPLS solves the network reconfiguration problems at the CE that are associated with Layer 2 Virtual Private Network (L2VPN) implementations. The current Cisco IOS software L2VPN implementation builds a point-to-point connection to interconnect the two attachment VCs of two peering customer sites. To communicate directly among all sites of an L2VPN network, a distinct emulated VC needs to be created between each pair of peering attachment VCs. For example, when two sites of the same L2VPN network are connected to the same PE, it requires that two separate emulated VCs be established towards a given remote site, instead of sharing a common emulated VC between these two sites. For a L2VPN customer who uses the service provider backbone to interconnect its LAN segments, the current implementation effectively turns its multiaccess broadcast network into a fully meshed point-to-point network, which requires extensive reconfiguration on the existing CE devices.

VPLS is a multipoint L2VPN architecture that connects two or more customer devices using EoMPLS bridging techniques. VPLS with EoMPLS uses an MPLS-based provider core, where the PE routers have to cooperate to forward customer Ethernet traffic for a given VPLS instance in the core.

VPLS uses the provider core to join multiple attachment circuits together to simulate a virtual bridge that connects the multiple attachment circuits together. From a customer point of view, there is no topology for VPLS. All of the CE devices appear to connect to a logical bridge emulated by the provider core.

Hierarchical Virtual Private LAN Service with MPLS to the Edge

In a flat or non-hierarchical VPLS configuration, a full mesh of pseudowires (PWs) is needed between all PE nodes. A pseudowire defines a VLAN and its corresponding pseudoport.

Hierarchical Virtual Private LAN Service (H-VPLS) reduces both signaling and replication overhead by using a combination of full-mesh and hub-and-spoke configurations. Hub-and-spoke configurations operate with split horizon to allow packets to be switched between pseudowires (PWs), which effectively reduce the number of PWs between PEs.

Figure 5-3 H-VPLS with MPLS to the Edge Network

 

In the H-VPLS with MPLS to the edge architecture, Ethernet Access Islands (EAIs) work in combination with a VPLS core network, with MPLS as the underlying transport mechanism. EAIs operate like standard Ethernet networks. In Figure 5-3, devices CE1, CE2a and CE2b reside in an EAI. Traffic from any CE devices within the EAI are switched locally within the EAI by the user-facing provider edge (UPE) device along the computed spanning-tree path. Each user-facing provider edge device is connected to one or more network-facing provider edge devices using PWs. The traffic local to the UPE is not forward to any network-facing provider edge devices.

VPLS Configuration Guidelines

When configuring VPLS on a SIP, consider the following guidelines:

  • For support of specific VPLS features by SIP, see Table 5-11 .
  • The SIPs support up to 4000 VPLS domains per Cisco 7600 series router.
  • The SIPs support up to 60 VPLS peers per domain per Cisco 7600 series router.
  • The SIPs support up to 30,000 pseudowires, used in any combination of domains and peers up to the 4000-domain or 60-peer maximums. For example, support of up to 4000 domains with 7 peers, or up to 60 peers in 500 domains.
  • When configuring VPLS on a Cisco 7600 SIP-600, consider the following guidelines:

Q-in-Q (the ability to map a single 802.1Q tag or a random double tag combination into a VPLS instance, a Layer 3 MPLS VPN, or an EoMPLS VC) is not supported.

H-VPLS with Q-in-Q edge—Requires a Cisco 7600 SIP-600 in the uplink, and any LAN port or Cisco 7600 SIP-600 on the downlink.

  • H-VPLS with MPLS edge requires either an OSM module, Cisco 7600 SIP-600, or Cisco 7600 SIP-400 in both the downlink (facing UPE) and uplink (MPLS core).
  • The Cisco 7600 SIP-400 and Cisco 7600 SIP-600 provide Transparent LAN Services (TLS) and Ethernet Virtual Connection Services (EVCS).
  • The Cisco 7600 SIP-400 does not support redundant PW links from a UPE to multiple NPEs.
  • For information about configuring VPLS on the SIPs, consider the guidelines in this document and then refer to the “Virtual Private LAN Services on the Optical Services Modules” section of the Optical Services Module Software Configuration Note for the Cisco 7600 series router at the following URL:

http://www.cisco.com/en/US/docs/routers/7600/install_config/12.2SX_OSM_config/mpls.html

VPLS Feature Compatibility

Table 5-11 provides information about where the VPLS features are supported.

 

Table 5-11 VPLS Feature Compatibility by SIP and SPA Combination

Feature
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

H-VPLS with MPLS edge

Not supported.

In Cisco IOS Release 12.2(33)SRA:

  • 2-Port Gigabit Ethernet SPA
  • 2-Port and 4-Port OC-3c/STM-1 POS SPA
  • 1-Port OC-12c/STM-4 POS SPA
  • 1-Port OC-48c/STM-16 POS SPA

In Cisco IOS release 15.2(1)S:

  • 1-Port Channelized OC12/STM-4 SPA
  • 2-Port and 4-Port Channelized T3 SPA
  • 8-Port Channelized T1/E1 SPA
  • 1-Port Channelized OC-3/STM-1 SPA
  • 1-Port Channelized OC48/STM/16/DS3 SPA
  • 2 and 4-Port Clear Channel T3/E3 SPA

In Cisco IOS Release 12.2(18)SXF and later:

  • 1-Port 10-Gigabit Ethernet SPA
  • 5-Port Gigabit Ethernet SPA
  • 10-Port Gigabit Ethernet SPA
  • 1-Port OC-192c/STM-64 POS/RPR SPA
  • 2-Port and 4-Port OC-48c/STM-16 POS SPA

Support for the following SPAs was added in Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port OC-48c/STM-16 POS SPA

H-VPLS with Q-in-Q edge

Not supported.

Not supported.

In Cisco IOS Release 12.2(18)SXF and later:

  • 1-Port 10-Gigabit Ethernet SPA
  • 5-Port Gigabit Ethernet SPA
  • 10-Port Gigabit Ethernet SPA
  • 1-Port OC-192c/STM-64 POS/RPR SPA
  • 2-Port and 4-Port OC-48c/STM-16 POS SPA

Support for the following SPAs was added in Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port OC-48c/STM-16 POS SPA

VPLS with point-to-multipoint EoMPLS and fully-meshed PE configuration

Not supported.

In Cisco IOS Release 12.2(33)SRA:

  • 2-Port Gigabit Ethernet SPA
  • 2-Port and 4-Port OC-3c/STM-1 POS SPA
  • 1-Port OC-12c/STM-4 POS SPA
  • 1-Port OC-48c/STM-16 POS SPA

In Cisco IOS release 15.2(1)S:

  • 1-Port Channelized OC12/STM-4 SPA
  • 2-Port and 4-Port Channelized T3 SPA
  • 8-Port Channelized T1/E1 SPA
  • 1-Port Channelized OC-3/STM-1 SPA
  • 1-Port Channelized OC48/STM/16/DS3 SPA
  • 2 and 4-Port Clear Channel T3/E3 SPA

In Cisco IOS Release 12.2(18)SXF and later:

  • 1-Port 10-Gigabit Ethernet SPA
  • 5-Port Gigabit Ethernet SPA
  • 10-Port Gigabit Ethernet SPA
  • 1-Port OC-192c/STM-64 POS/RPR SPA
  • 2-Port and 4-Port OC-48c/STM-16 POS SPA

Support for the following SPAs was added in Cisco IOS Release 12.2(33)SRA:

  • 2-Port and 4-Port OC-48c/STM-16 POS SPA

 

Configuring Asymmetric Carrier-Delay

During redundant link deployments where the remote network element is enabled, a link or port may be displayed as UP before the port or link is ready to forward data. This leads to traffic loss during switchover, as UP events are notified faster than the DOWN events leading to traffic loss.

Table 5-12 lists the differences between the conventional Carrier-Delay and Assymetric Carrier-Delay implementations.

Table 5-12 Conventional Carrier-Delay versus Assymetric Carrier-Delay

Conventional Carrier -Delay implementation
Assymetric Carrier-Delay implementation

You can configure Carrier-Delay on a main physical interface.

You can configure Assymetric Carrier-Delay on a main physical interface.

The acceptable limit to configure Carrier-Delay UP time is 4 seconds and above.

The acceptable limit to configure Carrier-Delay DOWN time is 11 milliseconds and above for SIP-600.

The acceptable limit to configure carrier-delay UP time is 4 seconds and above for SIP-200 and SIP-400 cards only if there is a scaled EVC configuration. Otherwise you can configure carrier-delay UP time to less than 4 seconds.

You can configure a single delay value for UP and DOWN events on a link.

You can configure separate delay values for each DOWN and UP events on a link.

Traffic losses and timer optimization issues when the link is UP or DOWN.

Delays are useful when the link is enabled or disabled (due to physical link failures/restoration or remote end events) before the actual link status is declared.

To prevent traffic loss in the SIP -200/400/600 line cards, you can configure seperate notifications or carrier-delay values during card boot UP/DOWN event notifications.

Erroneous cascading impact on other features in the SIP200/SIP400/SIP600 line cards. Example: An erroneous routing table convergence occurs where the link is available in the routing table.

Dependent features such as Routing Convergence and FRR are delayed on the local end.

Disruption of the fast readout links.

Delays streamlined ensuring stable topologies.

Restrictions and Usage Guidelines

  • The acceptable limit to configure Carrier-Delay DOWN time is eleven milliseconds and above for SIP-600 line cards. By default, Carrier-Delay is configured to 10 milliseconds during a card bootup. If you prefer to increase the default value of 10 milliseconds, you can manually configure and set the values on the SIP-600. The acceptable limit to configure carrier-delay UP time is 4 seconds and above for SIP-200 and SIP-400 cards only if there is a scaled EVC configuration. Otherwise you can configure carrier-delay UP time to less than 4 seconds.
  • As the Fast Link feature and Carrier-Delay features are mutually exclusive, Fast Link feature is enabled by default.
  • If you configure Carrier-Delay values, Fast Link feature is disabled on a line card.
  • Though the Fast Link feature is configured by default in the card, the Carrier-Delay feature overwrites the Fast Link feature when configured.
  • If you have not configured the Carrier-Delay values, Fast link feature values are utilized for DOWN event notification.

SUMMARY STEPS

1. enable

2. configure terminal

3. interface type slot/bay/port

4. carrier-delay [0-60]

5. carrier-delay [{up | down} [seconds]{msec| sec}]

6. end

DETAILED STEPS

Command or Action
Purpose

Step 1

enable

 

Router> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

 

Router# configure terminal

Enters global configuration mode.

Step 3

config # interface type slot/bay/port

 

P19_C7609-S(config)#int gig8/0/1

Selects the maininterface to configure.

Step 4

carrier-delay [0-60]

 

P19_C7609-S(config)#carrier-delay 20

Configures the conventional carrier-delay value in seconds.


Note Ensure that the Carrier-Delay values are configured within the acceptable range of 0-60. If not, the router displays an error message.


Step 5

carrier-delay [{up | down} [seconds]{msec| sec}]

 

P19_C7609-S(config-if)#carrier-delay up 8

P19_C7609-S(config-if)#carrier-delay down 5

Configures the Assymetric Carrier-Delay up or down value in milliseconds or seconds.

Note ‘Four seconds’ is the lower limit for the Assymmetric Carrier-Delay UP timer value, on a scaled EVC configuration. If you configure the UP timer to be lesser than 4secs the following message is displayed:

Minimum carrier-delay for UP timer is 4secs if there is a scaled EVC configuration

Step 6

end

 

Exits the configuration mode.


NoteOnce you have configured assymetric carrier delay (ACD) UP timer, the link should come UP only after the configured delay.
A situation where the remote end comes UP sooner than the local end(where ACD is configured) is expected, as the remote end does not have any asymetric carrier delay configured. SPA detects and then signals to the remote end that the PORT is UP. Whereas the local end (ACD configured), will come UP only after the UP timer is configured.


Verification

You can use the show run command to display the Carrier-Delay configurations on an SIP-200/400 physical interface.

 
sh run int Fa2/0/0
Building configuration...
 
Current configuration: 219 bytes
!
interface FastEthernet2/0/0
ip address 32.0.0.1 255.255.255.0
logging event link-status
carrier-delay up 10
carrier-delay down 5

end

Configuring BFD over VCCV on SIP-400

BFD over VCCV is a mechanism for operation and management of pseudowires to enable fault detection and diagnostics.Bidirectional forwarding detection (BFD) is a protocol that detects faults in the bidirectional path between two forwarding engines. In pseudowires, BFD uses the virtual circuit connectivity verification (VCCV) for detecting data plane failures. VCCV provides a control channel that is associated with a pseudowire (PW) and the corresponding operations and management functions.

MPLS pseudowires can dynamically signal or statically configure virtual circuit (VC) labels. VCCV control channel (CC) types define possible control channels that VCCV can support and connection verification (CV) types indicate the types of CV packets and protocols that can be sent on the specified control channel. In dynamically signalled pseudowires, the CC types and CV types are also signalled. In statically configured pseudowires, the CC and CV types must be configured on both ends of the pseudowire.

The following BFD over VCCV modes are possible on pseudowires:

  • BFD over VCCV on static pseudowire with attachment circuit signaling
  • BFD over VCCV on static pseudowire with out attachment circuit signaling
  • BFD over VCCV on dynamic pseudowire with out attachment circuit signaling

Configuration Restrictions

Follow these restrictions while configuring BFD over VCCV on SIP-400.

  • Only BFD over VCCV Type1 without internet protocol (IP) /user datagram protocol (UDP) is supported. In VCCV Type1, traffic follows the same path as pseudowire data traffic and VCCV Type 1 can be used only for MPLS pseudowires with control word.
  • L2TPv3 is currently not supported.
  • Pseudowire redundancy is not supported.
  • Only ATM is supported as attachment circuit.
  • Up to 1200 pseudowires can be enabled for BFD over VCCV.
  • When BFD over VCCV is enabled on the pseudowire, switched virtual interface (SVI) based ethernet over multi protocol label switching (EoMPLS) is not supported.
  • When BFD over VCCV is enabled on the pseudowire, multipoint core-facing interface is not supported.
  • BFD over VCCV sessions are supported only on single-segment pseudowires between provider edge routers (PEs).
  • BFD over VCCV sessions between terminating PE routers (T-PEs) and switching PE routers (S-PEs) are not supported.
  • BFD over VCCV sessions are supported only on multi-segment pseudowires between terminating PE routers (T-PEs).
  • Only these SPAs are supported on the line card edge that faces the attachment circuit:

2-Port OC-3c/STM-1 ATM SPA

4-Port OC-3c/STM-1 ATM SPA

1-Port OC-12c/STM-4 ATM SPA

1-Port OC-48c/STM-16 ATM SPA

Configuration Steps

Perform these steps to configure BFD over VCCV.

SUMMARY STEPS


Step 1 enable

Step 2 configure terminal

Step 3 bfd-template single-hop bfd-template-name

Step 4 interval min-tx msec min-rx msec multiplier number

Step 5 exit

Step 6 pseudowire-class pseudowire-class-name

Step 7 encapsulation mpls

Step 8 vccv bfd template bfd-template-name

Step 9 exit

Step 10 interface atm slot/subslot/port

Step 11 pvc vpi/vci l2transport

Step 12 xconnect destination vc-id pseudowire-class pseudowire-class-name

Step 13 exit

DETAILED STEPS

Command
Purpose

Step 1

Router> enable

Enables privileged EXEC mode. Enter your password if prompted.

Step 2

Router# configure terminal

Enters global configuration mode.

Step 3

Router(config)# bfd-template single-hop bfd-template-name

Specifies the BFD template.

Step 4

Router(config-bfd)# interval min-tx msec min-rx msec multiplier number

Router(config-bfd)# interval min-tx 500 min-rx 500 multiplier 3

Specifies the following BFD VCCV parameters:

  • min-tx : Minimum transmission interval in milliseconds, that the local system uses when transmitting BFD control packets. The valid range is 50-999.
  • min-rx : Minimum receiving interval in milliseconds, between received control packets that this system is capable of supporting. The valid range is 50-999.
  • multiplier : The negotiated transmit interval, multiplied by this value, provides the detection time for the transmitting system in asynchronous mode.

Step 5

Router(config-bfd)# exit

Exits from the BFD template configuration mode.

Step 6

Router(config)# pseudowire-class pseudowire-class-name

Router(config)# pseudowire-class BFD

Specifies the pseudowire class.

Step 7

Router(config-pw-class)# encapsulation mpls

Specifies the encapsulation method.

Step 8

Router(config-pw-class)# vccv bfd template bfd-template-name

Router(config-pw-class)# vccv bfd template bfd-template

Applies the configured BFD interval timers to BFD VCCV pseudowire class.

Step 9

Router(config-pw-class)# exit

Exits from the pseudowire class configuration mode.

Step 10

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

Router(config)# interface atm 3/0/0

Specifies an ATM interface and enters interface configuration mode.

Step 11

Router(config-if)# pvc vpi/vci l2transport

Router(config-if)# pvc 2/101 l2transport

Assigns a virtual path identifier (VPI) and a virtual circuit identifier (VCI). The l2transport keyword indicates that the permanent virtual circuit (PVC) is a switched PVC instead of a terminated PVC.

Step 12

Router(config-atm-pvc)# xconnect destination vc-id pseudowire-class pseudowire-class-name

Router(config-atm-pvc)# xconnec t 16.1.1.1 2 pseudowire-class BFD

Specifies the virtual circuit (VC).

  • destination : Specifies the loopback address of the remote router.
  • vc-id : Identifies the virtual circuit between the PE routers at each end point of the VC. It must be unique for each VC.

Step 13

Router(config-atm-pvc)# exit

Exits from the ATM PVC configuration mode.


NoteIf you apply or remove a QoS service policy on the ATM PVC, then the configured BFD VCCV sessions are also renegotiated and a minimal drop in data traffic occurs.


Verifying BFD VCCV Configuration

Use the show mpls l2 vc command to verify the BFD VCCV configuration.

RouterA# show mpls l2transport vc detail
Local interface: AT3/0/0 up, line protocol up, ATM AAL5 2/101 up
Destination address: 23.1.1.1, VC ID: 1, VC status: up
Output interface: Gi5/1, imposed label stack {2559}
Preferred path: not configured
Default path: active
Next hop: 9.1.1.2
Create time: 00:18:39, last status change time: 00:04:50
Signaling protocol: LDP, peer 23.1.1.1:0 up
Targeted Hello: 22.1.1.1(LDP Id) -> 23.1.1.1, LDP is UP
Status TLV support (local/remote) : enabled/supported
LDP route watch : enabled
Label/status state machine : established, LruRru
Last local dataplane status rcvd: No fault
Last local SSS circuit status rcvd: No fault
Last local SSS circuit status sent: No fault
Last local LDP TLV status sent: No fault
Last remote LDP TLV status rcvd: No fault
Last remote LDP ADJ status rcvd: No fault
MPLS VC labels: local 16, remote 2559
Group ID: local 0, remote 0
MTU: local 4470, remote 4470
Remote interface description: ^M Sequencing: receive disabled, send disabled
Control Word: On (configured: autosense)
VCCV BFD protection active
BFD Template - bfd
CC Type - 1
CV Type - fault detection only with IP/UDP headers
SSO Descriptor: 23.1.1.1/1, local label: 16
SSM segment/switch IDs: 8195/4097 (used), PWID: 12290
VC statistics:
transit packet totals: receive 225, send 89
transit byte totals: receive 13300, send 5340
transit packet drops: receive 0, seq error 0, send 0

 

Alternatively, you can also use the show bfd neighbors command from the destination router to verify the configuration.

RouterB# show bfd neighbors mpls-pw 22.1.1.1 vcid 1 detail
NeighAddr LD/RD RH/RS State Int
22.1.1.1 :1 1/1 Up Up N/A
Session state is UP and not using echo function.
OurAddr: 0.0.0.0
Local Diag: 0, Demand mode: 0, Poll bit: 0

MinTxInt: 500000, MinRxInt: 500000, Multiplier: 3

Received MinRxInt: 500000, Received Multiplier: 3
Holddown (hits): 1372(2), Hello (hits): 500(4051)
Rx Count: 3200, Rx Interval (ms) min/max/avg: 1/488/91 last: 128 ms ago
Tx Count: 3203, Tx Interval (ms) min/max/avg: 40/472/91 last: 128 ms ago
Elapsed time watermarks: 0 0 (last: 0)
Registered protocols: Xconnect
Uptime: 00:04:49
Last packet: Version: 1 - Diagnostic: 0
State bit: Up - Demand bit: 0
Poll bit: 0 - Final bit: 1
Multiplier: 3 - Length: 24
My Discr.: 1 - Your Discr.: 1
Min tx interval: 500000 - Min rx interval: 500000

Min Echo interval: 0

Debugging the BFD Configuration

Use these debug commands to troubleshoot the BFD VCCV configuration.

Command
Purpose

debug condition xconnect peer ipaddress vcid vcid

Allows conditional filtering of debug messages based on VC ID.

debug mpls l2 vc vccv events

Debugs any transport over MPLS (AToM) VCCV events.

debug mpls l2 vc vccv bfd events

Enables the debug event messages during the creation of a BFD session. This command enables debug event messages when BFD sends the data plane fault notification to L2VPN and also when L2VPN sends the attachment circuit signaling status to BFD.

Configuring MPLS Features on a SIP

Many of the MPLS features supported on the FlexWAN and Enhanced FlexWAN modules on the Cisco 7600 series router are also supported by the SIPs. For a list of the supported MPLS features on the SIPs, see Chapter4, “Overview of the SIPs and SSC”

This section describes those MPLS features that have SIP-specific configuration guidelines. After you review the SIP-specific guidelines described in this document, then refer to the following URL for more information about configuring MPLS features:

http://www.cisco.com/en/US/docs/routers/7600/install_config/flexwan_config/flexmpls.html

This section includes the following topics:

Configuring Any Transport over MPLS on a SIP

Any Transport over MPLS (AToM) transports Layer 2 packets over a Multiprotocol Label Switching (MPLS) backbone. AToM uses a directed Label Distribution Protocol (LDP) session between edge routers for setting up and maintaining connections. Forwarding occurs through the use of two levels of labels, switching between the edge routers. The external label (tunnel label) routes the packet over the MPLS backbone to the egress Provider Edge (PE) at the ingress PE. The VC label is a demuxing label that determines the connection at the tunnel endpoint (the particular egress interface on the egress PE as well as the virtual path identifier [VPI]/virtual channel identifier [VCI] value for an ATM Adaptation Layer 5 [AAL5] protocol data unit [PDU], the data-link connection identifier [DLCI] value for a Frame Relay PDU, or the virtual LAN [VLAN] identifier for an Ethernet frame).

For specific information about configuring AToM features, refer to the FlexWAN and Enhanced FlexWAN Module Installation and Configuration Note located at the following URL:

http://www.cisco.com/en/US/docs/routers/7600/install_config/flexwan_config/flexmpls.html


NoteWhen referring to the FlexWAN documentation, be sure to note any SIP-specific configuration guidelines described in this document.


Cisco 7600 SIP-200 AToM Features

The Cisco 7600 SIP-200 supports the following AToM features:

  • ATM over MPLS (ATMoMPLS)—AAL5 VC mode
  • Ethernet over MPLS (EoMPLS)—(Single cell relay) VC mode
  • Frame Relay over MPLS (FRoMPLS)
  • FRoMPLS with dMLFR—Supported between the CE and PE devices.
  • High-Level Data Link Control (HDLC) over MPLS (HDLCoMPLS)
  • PPP over MPLS (PPPoMPLS)—Not supported with dMLPPP or dLFI
  • Hierarchical QoS for EoMPLS VCs

Cisco 7600 SIP-200 AToM Configuration Guidelines

When configuring AToM with a Cisco 7600 SIP-200, consider the following guidelines:

  • You cannot use a SIP-200 and an Ethernet SPA on the customer-facing side because the Ethernet SPA is a Layer 3 only interface.
  • Because the SIP-200 supports WAN interfaces, you can use the SIP-200 for non-Ethernet access (FR,HDLC,ATM,PPP) at the customer-facing side.
  • For VLAN-based xconnect (also called line card-based EoMPLS), the customer-facing port must be a Layer 2 port and the backbone-facing card must be a Layer 3 port.
  • The SIP-200 does not supportdot1q subinterface-based xconnect towards the edge.

Cisco 7600 SIP-400 AToM Features

The Cisco 7600 SIP-400 supports the following AToM features:

  • ATMoMPLS—AAL0 mode (single cell relay only. From 12.2(33) release onwards packed cell relay)
  • ATMoMPLS—AAL5 mode
  • ATMoMPLS— Port mode cell relay (from Cisco IOS 12.2(33) SRD release onwards)
  • EoMPLS—Port mode
  • EoMPLS—VLAN mode
  • FRoMPLS—DLCI mode
  • TDM over MPLS (Starting from Cisco IOS release 12.2(33) SRD onwards)
  • Beginning in Cisco IOS Release 12.2(33)SRA:

Hierarchical QoS for EoMPLS VCs

HDLCoMPLS

PPPoMPLS

ATM local switching

Cisco 7600 SIP-400 AToM Configuration Guidelines

When configuring AToM with a Cisco 7600 SIP-400, consider the following guidelines:

  • The Cisco 7600 SIP-400 is not supported with a Supervisor Engine 1, Supervisor Engine 1A, Supervisor Engine 2, or Supervisor Engine 720 PFC3A.
  • The Cisco 7600 SIP-400 is not supported with PFC-2-based systems.
  • For AToM in Cisco IOS 12.2SX releases, the Cisco 7600 SIP-400 does not support the following features when they are located in the data path. This means you should not configure the following features if the SIP is facing the customer edge (CE) or the MPLS core:

HDLCoMPLS

PPPoMPLS

VPLS

  • For AToM beginning in Cisco IOS Release 12.2(33)SRA, the Cisco 7600 SIP-400 supports the following features on CE-facing interfaces:

HDLCoMPLS

PPPoMPLS

VPLS

  • The Cisco 7600 SIP-400 supports EoMPLS with directly connected provider edge (PE) devices when the Cisco 7600 SIP-400 is on the MPLS core side of the network.
  • The Cisco 7600 SIP-400 does not support the ability to enable or disable tunneling of Layer 2 packets, such as for the VLAN Trunking Protocol (VTP), Cisco Discovery Protocol (CDP), and bridge protocol data unit (BPDU). The Cisco 7600 SIP-400 tunnels BPDUs, and always blocks VTP and CDP packets from the tunnel.
  • In ATMoMPLS AAL5 and cell mode, the Cisco 7600 SIP-400 supports non-matching VPIs/VCIs between PEs if the Cisco 7600 SIP-400 is on both sides of the network.
  • The Cisco 7600 SIP-400 supports matching on FR-DE to set MPLS-EXP for FRoMPLS.
  • The Cisco 7600 SIP-400 does not support the following QoS classification features with AToM:

Matching on data-link connection identifier (DLCI) is unsupported.

Matching on virtual LAN (VLAN) is unsupported.

Matching on class of service (CoS) is unsupported in Cisco IOS Release 12.2(18)SXE and Cisco IOS Release 12.2(18)SXE2 only. Beginning in Cisco IOS Release 12.2(18)SXF, it is supported with the 2-Port Gigabit Ethernet SPA.

Matching on input interface is unsupported.

Matching on packet length is unsupported.

Matching on media access control (MAC) address is unsupported.

Matching on protocol type, including Border Gateway Protocol (BGP), is unsupported.

Understanding MPLS Imposition on the Cisco 7600 SIP-400 to Set MPLS Experimental Bits

The MPLS imposition function encapsulates non-MPLS frames (such as Ethernet, VLAN, Frame Relay, ATM, or IP) into MPLS frames. MPLS disposition performs the reverse function.

An input QoS policy map is applied to ingress packets before MPLS imposition takes place. This means that the packets are treated as non-MPLS frames, so any MPLS-related matches have no effect. In the case of marking experimental (EXP) bits using the set mpls experimental command, the information is passed to the AToM or MPLS component to set the EXP bits. After imposition takes place, the frame becomes an MPLS frame and an output QoS policy map (if it exists) can apply MPLS-related criteria.

On the egress side, an output QoS policy map is applied to the egress packets after MPLS disposition takes place. This means that packets are treated as non-MPLS frames, so any MPLS-related criteria has no effect. Before disposition, the frame is an MPLS frame and the input QoS policy map (if it exists) can apply MPLS-related criteria.

The Encoded Address Recognition Logic (EARL) is a centralized processing engine for learning and forwarding packets based upon MAC address on the Cisco 7600 series router supervisor engines. The EARL stores the VLAN, MAC address, and port relationships. These relationships are used to make switching decisions in hardware. The EARL engine also performs MPLS imposition, and the MPLS EXP bits are copied either from the IP TOS field (using trust dscp or trust precedence mode), or from the DBUS header QoS field (using trust cos mode).

When using the 2-Port Gigabit Ethernet SPA with the Cisco 7600 SIP-400 as the customer-side interface configured for 802.1Q encapsulation for IP imposition with MPLS, the Layer 2 CoS value is not automatically copied into the corresponding MPLS packet’s EXP bits. Instead, the value in the IP precedence bits is copied.

To maintain the 802.1Q CoS values, classify the imposition traffic on the customer-facing Gigabit Ethernet interface in the input direction to match on CoS value, and then set the MPLS experimental action for that class as shown in the following example:

Router(config)# class-map cos0
Router(config-cmap)# match cos 0
Router(config-cmap)# exit
!
Router(config)# class-map cos1
Router(config-cmap)# match cos 1
Router(config-cmap)# exit
!
Router(config)# policy-map policy1
Router(config-pmap)# class cos0
Router(config-pmap-c)# set mpls experimental imposition 0
Router(config-pmap-c)# exit
Router(config-pmap)# class cos1
Router(config-pmap-c)# set mpls experimental imposition 1

Cisco 7600 SIP-600 AToM Features

The Cisco 7600 SIP-600 supports the following AToM features:

  • Any Transport over MPLS (AToM) support—EoMPLS only (Encoded Address Recognition Logic [EARL]-based and SIP-based EoMPLS)

Configuring Hierarchical Virtual Private LAN Service (H-VPLS) with MPLS to the Edge

The Cisco 7600 SIP-400 and Cisco 7600 SIP-600 support the H-VPLS with MPLS to the Edge feature. For more information about VPLS support on the SIPs, see the “Configuring Virtual Private LAN Service” section.

Configuring VRF aware IPv6 tunnel

The 7600-SIP-200 and 7600-SIP-400 support the VRF aware IPv6 tunnel on c7600. The current IPv6 tunneling feature on c7600 does not support Virtual Routing and Forwarding (VRF) awareness. The forwarding table lookups for IPv6 overlay addresses and IPv4 transport addresses are performed in the global routing tables. This feaure extends the tunneling support for IPv6 overlay addresses in VRF.

Restrictions for VRF aware IPv6 tunnels

Following restrictions apply to the VRF aware IPv6 tunnels feature:

  • This feature supports the IPv6IP and 6to4 tunnels mode.
  • Due to EARL limitation, the same source tunnels across VRFs are not supported.
  • The tunnel source and the tunnel destination should be in the same VRF instance.
  • The tunnel IPv4 transport addresses and the physical interface where the tunnel traffic exits, should be in the same VRF instance.
  • The incoming IPv6 interface and the tunnel should be in the same VRF instance.
  • This feature does not support IPv6IP auto-tunnels and ISATAP.

Configuring VRF aware IPv6 tunnel

For information on VRF aware IPv6 tunnel configurations, see: http://www.cisco.com/en/US/docs/routers/7600/install_config/ES40_config_guide/es40_chap13.html#wp1524288

Configuring MPLS Traffic Engineering Class-Based Tunnel Selection (CBTS) on the Cisco 7600 SIP-600

Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Class-Based Tunnel Selection (CBTS) enables you to dynamically route and forward traffic with different class of service (CoS) values onto different TE tunnels between the same tunnel headend and the same tailend. The TE tunnels can be regular TE or DiffServ-aware TE (DS-TE) tunnels.

The set of TE (or DS-TE) tunnels from the same headend to the same tailend that you configure to carry different CoS values is referred to as a “tunnel bundle.” Tunnels are “bundled” by creating a master tunnel and then attaching member tunnels to the master tunnel. After configuration, CBTS dynamically routes and forwards each packet into the tunnel that meets the following requirements:

  • Is configured to carry the CoS of the packet
  • Has the right tailend for the destination of the packet

Because CBTS offers dynamic routing over DS-TE tunnels and requires minimum configuration, it greatly eases deployment of DS-TE in large-scale networks.

CBTS can distribute all CoS values on eight different tunnels.

CBTS also allows the TE tunnels of a tunnel bundle to exit headend routers through different interfaces.

CTBS configuration involves performing the following tasks:

  • Creating multiple (DS-) TE tunnels withe same headend and tailend and indicating on each of these tunnels which CoSs are to be transported on the tunnel.
  • Creating a master tunnel, attaching the member tunnels to it, and making the master tunnel visible for routing.

MPLS Traffic Engineering Class-Based Tunnel Selection (CBTS) Configuration Guidelines

When configuring MPLS Traffic Engineering Class-Based Tunnel Selection (CBTS), consider the following guidelines:

  • CBTS has the following prerequisites:

MPLS enabled on all tunnel interfaces

Cisco Express Forwarding (CEF) or distributed CEF (dCEF) enabled in general configuration mode

  • CBTS has the following restrictions:

For a given destination, all CoS values are carried in tunnels terminating at the same tailend. Either all CoS values are carried in tunnels or no values are carried in tunnels. In other words, for a given destination, you cannot map some CoS values in a DS-TE tunnel and other CoS values in a Shortest Path First (SPF) Label Distribution Protocol (LDP) or SPF IP path.

No LSP is established for the master tunnel and regular traffic engineering attributes (bandwidth, path option, fast reroute) are irrelevant on a master tunnel. TE attributes (bandwidth, bandwidth pool, preemption, priorities, path options, and so on) are configured completely independently for each tunnel.

CBTS does not allow load-balancing of a given EXP value in multiple tunnels. If two or more tunnels are configured to carry a given experimental (EXP) value, CBTS picks one of these tunnels to carry this EXP value.

CBTS supports aggregate control of bumping (that is, it is possible to define default tunnels to be used if other tunnels go down. However, CBTS does not allow control of bumping if the default tunnel goes down. CBTS does not support finer-grain control of bumping. For example, if the voice tunnel goes down, redirect voice to T2, but if video goes down, redirect to T3.

The operation of CBTS is not supported with Any Transport over MPLS (AToM), MPLS TE Automesh, or label-controlled (LC)-ATM.

Creating Multiple MPLS Member TE or DS-TE Tunnels from the Same Headend to the Same Tailend

SUMMARY STEPS


Step 1 interface tunnel number

Step 2 ip unnumbered type number

Step 3 tunnel destination { hostname | ip-address }

Step 4 tunnel mode mpls traffic-eng

Step 5 tunnel mpls traffic-eng bandwidth [ sub-pool | global ] bandwidth

Step 6 tunnel mpls traffic-eng exp [ list-of-exp-values ] [ default ]

Step 7 exit

DETAILED STEPS

Perform the following task to create multiple MPLS member TE or DS-TE tunnels with the same headend and same tailend and to configure EXP values to be carried by each of these tunnels. The procedure begins in global configuration mode.

 

Command
Purpose

Step 1

Router(config)# interface tunnel number

Configures a tunnel interface type and enters interface configuration mode.

  • number —Number of the tunnel interface that you want to create or configure.

Step 2

Router(config-if)# ip unnumbered type number

Enables IP processing on an interface without assigning an explicit IP address to the interface.

  • type —Type of another interface on which the router has an assigned IP address.
  • number —Number of another interface on which the router has an assigned IP address. It cannot be another unnumbered interface.

Step 3

Router(config-if)# tunnel destination { hostname | ip-address }

Specifies the destination of the tunnel for this path option.

  • hostname —Name of the host destination.
  • ip-address —IP address of the host destination expressed in four-part, dotted decimal notation.

Step 4

Router(config-if)# tunnel mode mpls traffic-eng

Sets the mode of a tunnel to MPLS for TE.

Step 5

Router(config-if)# tunnel mpls traffic-eng bandwidth [ sub-pool | global ] bandwidth

Configures the bandwidth for the MPLS TE tunnel. If automatic bandwidth is configured for the tunnel, use the tunnel mpls traffic-eng bandwidth command to configure the initial tunnel bandwidth, which is adjusted by the auto-bandwidth mechanism.

  • sub-pool —(Optional) Indicates a subpool tunnel.
  • global —(Optional) Indicates a global pool tunnel. Entering this keyword is not necessary, for all tunnels are global pool in the absence of the sub-pool keyword. But if users of pre-DiffServ-aware Traffic Engineering (DS-TE) images enter this keyword, it is accepted.
  • bandwidth —Bandwidth, in kilobits per second, set aside for the MPLS traffic engineering tunnel. Range is between 1 and 4294967295.

Note You can configure any existing mpls traffic-eng command on these TE or DS-TE tunnels.

Step 6

Router(config-if)# tunnel mpls traffic-eng exp [ list-of-exp-values ] [ default ]

Specifies an EXP value or values for an MPLS TE tunnel.

  • list-of-exp-values —EXP value or values that are are to be carried by the specified tunnel. Values range from 0 to 7.
  • default —The specified tunnel is to carry all EXP values that are:

Not explicitly allocated to another tunnel

Allocated to a tunnel that is currently down

Step 7

Router(config-if)# exit

Exits to global configuration mode.

Step 8

 

Repeat steps 1 through 7 on the same headend router to create additional tunnels from this headend to the same tailend.

Creating a Master Tunnel, Attaching Member Tunnels, and Making the Master Tunnel Visible

SUMMARY STEPS


Step 1 interface tunnel number

Step 2 ip unnumbered type number

Step 3 tunnel destination { hostname | ip-address }

Step 4 tunnel mode mpls traffic-eng exp-bundle master

Step 5 tunnel mode mpls traffic-eng exp-bundle member tunnel-id

Step 6 tunnel mpls traffic-eng autoroute announce

Step 7 tunnel mpls traffic-eng autoroute metric absolute | relative value

DETAILED STEPS

Perform the followings task to create a master tunnel, attach member tunnels to it, and make the master tunnel visible for routing. The procedure begins in global configuration mode.

 

Command
Purpose

Step 1

Router(config)# interface tunnel number

Configures a tunnel interface type and enters interface configuration mode.

  • number —Number of the tunnel interface that you want to create or configure.

Step 2

Router(config-if)# ip unnumbered type number

Enables IP processing on an interface without assigning an explicit IP address to the interface.

  • type —Type of another interface on which the router has an assigned IP address.
  • number —Number of another interface on which the router has an assigned IP address. It cannot be another unnumbered interface.

Step 3

Router(config-if)# tunnel destination { hostname | ip-address }

Specifies the destination of the tunnel for this path option.

  • hostname —Name of the host destination.
  • ip-address —IP address of the host destination expressed in four-part, dotted decimal notation.

Step 4

Router(config-if)# tunnel mode mpls traffic-eng exp-bundle master

Specifies this is the master tunnel for the CBTS configuration.

Step 5

Router(config-if)# tunnel mode mpls traffic-eng exp-bundle member tunnel-id

Attaches a member tunnel to the master tunnel.

  • tunnel-id —Number of the tunnel interface to be attached to the master tunnel.

Repeat this command for each member tunnel.

Step 6

Router(config-if)# tunnel mpls traffic-eng autoroute announce

Specifies that the Interior Gateway Protocol (IGP) should use the tunnel (if the tunnel is up) in its enhanced SPF calculation.

Step 7

Router(config-if)# tunnel mpls traffic-eng autoroute metric absolute | relative value

(Optional) Specifies the MPLS TE tunnel metric that the IGP enhanced SPF calculation uses.

  • absolute —Indicates the absolute metric mode; you can enter a positive metric value.
  • relative —Indicates the relative metric mode; you can enter a positive, negative, or zero value.
  • value —Metric that the IGP enhanced SPF calculation uses. The relative value can be from –10 to 10.

Note Even though the value for a relative metric can be from –10 to +10, configuring a tunnel metric with a negative value is considered a misconfiguration. If the metric to the tunnel tailend appears to be 4 from the routing table, then the cost to the tunnel tailend router is actually 3 because 1 is added to the cost for getting to the loopback address. In this instance, the lowest value that you can configure for the relative metric is -3.


NoteAlternatively, static routing could be used instead of autoroute to make the TE or DS-TE tunnels visible for routing.


Verifying That the MPLS TE or DS-TE Tunnels Are Operating and Announced to the IGP

The following show commands can be used to verify that the MPLS TE or DS-TE tunnels are operating and announced to the IGP. The commands are all entered in privileged EXEC configuration mode.

 

Command
Purpose

Router# show mpls traffic-eng topology { A . B .C. D | igp-id { isis nsap-address | ospf A . B .C. D } [ brief ]

Shows the MPLS traffic engineering global topology as currently known at this node.

  • A . B .C. D —Specifies the node by the IP address (router identifier to interface address).
  • igp-id —Specifies the node by IGP router identifier.
  • isis nsap-address —Specifies the node by router identification (nsap-address) if you are using IS-IS.
  • ospf A . B .C. D —Specifies the node by router identifier if you are using OSPF.
  • brief —Provides a less detailed version of the topology.

Router# show mpls traffic-eng exp

Displays EXP mapping.

Router# show ip cef [ type number ] [ detail ]

Displays entries in the forwarding information base (FIB) or displays a summary of the FIB.

  • type number —Identifies the interface type and number for which to display FIB entries.
  • detail —Displays detailed FIB entry information.

Router# show mpls forwarding-table [ network { mask | length } [ detail ]

Displays the contents of the MPLS label forwarding information base (LFIB).

  • network —Identifies the destination network number.
  • mask —Identifies the network mask to be used with the specified network.
  • length —Identifies the number of bits in the destination mask.
  • detail —Displays information in long form (includes length of encapsulation, length of MAC string, maximum transmission unit [MTU], and all labels).

Router# show mpls traffic-eng autoroute

Displays tunnels that are announced to the Interior Gateway Protocol (IGP).

The show mpls traffic-eng topology command output displays the MPLS TE global topology:

Router# show mpls traffic-eng topology 10.0.0.1
 
IGP Id: 10.0.0.1, MPLS TE Id:10.0.0.1 Router Node (ospf 10 area 0) id 1
link[0]: Broadcast, DR: 180.0.1.2, nbr_node_id:6, gen:18
frag_id 0, Intf Address:180.0.1.1
TE metric:1, IGP metric:1, attribute_flags:0x0
SRLGs: None
physical_bw: 100000 (kbps), max_reservable_bw_global: 1000 (kbps)
max_reservable_bw_sub: 0 (kbps)
Global Pool Sub Pool
Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 0 1000 0
bw[1]: 0 1000 0
bw[2]: 0 1000 0
bw[3]: 0 1000 0
bw[4]: 0 1000 0
bw[5]: 0 1000 0
bw[6]: 0 1000 0
bw[7]: 100 900 0
 
link[1]: Broadcast, DR: 180.0.2.2, nbr_node_id:7, gen:19
frag_id 1, Intf Address:180.0.2.1
TE metric:1, IGP metric:1, attribute_flags:0x0
SRLGs: None
physical_bw: 100000 (kbps), max_reservable_bw_global: 1000 (kbps)
max_reservable_bw_sub: 0 (kbps)
Global Pool Sub Pool
Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 0 1000 0
bw[1]: 0 1000 0
bw[2]: 0 1000 0
bw[3]: 0 1000 0
bw[4]: 0 1000 0
bw[5]: 0 1000 0
bw[6]: 0 1000 0
bw[7]: 0 1000 0
 

The show mpls traffic-eng exp command output displays EXP mapping information about a tunnel:

Router# show mpls traffic-eng exp
 
Destination: 10.0.0.9
Master: Tunnel10 Status: IP
 
Members: Status Conf EXP Actual EXP
Tunnel1 UP/ACTIVE 5 5
Tunnel2 UP/ACTIVE default 0 1 2 3 4 6 7
Tunnel3 UP/INACTIVE(T) 2
Tunnel4 DOWN 3
Tunnel5 UP/ACTIVE(NE)
 
(T)=Tailend is different to master
(NE)=There is no exp value configured on this tunnel.
 

The show ip cef detail command output displays detailed FIB entry information for a tunnel:

Router# show ip cef tunnel1 detail
 
IP CEF with switching (Table Version 46), flags=0x0
31 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 2
2 instant recursive resolutions, 0 used background process
8 load sharing elements, 8 references
6 in-place/0 aborted modifications
34696 bytes allocated to the FIB table data structures
universal per-destination load sharing algorithm, id 9EDD49E1
1(0) CEF resets
Resolution Timer: Exponential (currently 1s, peak 1s)
Tree summary:
8-8-8-8 stride pattern
short mask protection disabled
31 leaves, 23 nodes using 26428 bytes
Table epoch: 0 (31 entries at this epoch)
Adjacency Table has 13 adjacencies
10.0.0.9/32, version 45, epoch 0, per-destination sharing
0 packets, 0 bytes
tag information set, all rewrites inherited
local tag: tunnel head
via 0.0.0.0, Tunnel1, 0 dependencies
traffic share 1
next hop 0.0.0.0, Tunnel1
valid adjacency
tag rewrite with Tu1, point2point, tags imposed {12304}
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes
 

The show mpls forwarding-table detail command output displays detailed information from the MPLS LFIB:

Router# show mpls forwarding 10.0.0.9 detail
 
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
Tun hd Untagged 10.0.0.9/32 0 Tu1 point2point
MAC/Encaps=14/18, MRU=1500, Tag Stack{12304}, via Fa6/0
00027D884000000ED70178A88847 03010000
No output feature configured
Per-exp selection: 1
Untagged 10.0.0.9/32 0 Tu2 point2point
MAC/Encaps=14/18, MRU=1500, Tag Stack{12305}, via Fa6/1
00027D884001000ED70178A98847 03011000
No output feature configured
Per-exp selection: 2 3
Untagged 10.0.0.9/32 0 Tu3 point2point
MAC/Encaps=14/18, MRU=1500, Tag Stack{12306}, via Fa6/1
00027D884001000ED70178A98847 03012000
No output feature configured
Per-exp selection: 4 5
Untagged 10.0.0.9/32 0 Tu4 point2point
MAC/Encaps=14/18, MRU=1500, Tag Stack{12307}, via Fa6/1
00027D884001000ED70178A98847 03013000
No output feature configured
Per-exp selection: 0 6 7
 

The show mpls traffic-eng autoroute command output displays tunnels that are announced to the Interior Gateway Protocol (IGP).

Router# show mpls traffic-eng autoroute
 
MPLS TE autorouting enabled
destination 10.0.0.9, area ospf 10 area 0, has 4 tunnels
Tunnel1 (load balancing metric 20000000, nexthop 10.0.0.9)
(flags: Announce)
Tunnel2 (load balancing metric 20000000, nexthop 10.0.0.9)
(flags: Announce)
Tunnel3 (load balancing metric 20000000, nexthop 10.0.0.9)
(flags: Announce)
Tunnel4 (load balancing metric 20000000, nexthop 10.0.0.9)
(flags: Announce)
 

Troubleshooting

This section describes how to troubleshoot common ATMoMPLS and EoMPLS issues.

 

Scenarios/Problems
Solution

How do I list all the L2transport VCs and their status (whether up or down), and also the pseudowire destination IP address?

Use the show mpls l2 vc command. This example displays detailed status for a specific VC:

Router# show mpls l2 vc 1100 detail

Local interface: VFI VPLS-1100 up

MPLS VC type is VFI, internetworking type is Ethernet

Destination address: 1.1.1.1,VC ID:1100, VC status: up

Output interface: Tu0,imposed label stack {27 17}

Preferred path: not configured

Default path: active

Next hop:point2point

Create time:2d23h, last status change time: 2d23h

Signaling protocol: LDP, peer 1.1.1.1:0 up

MPLS VC labels: local 17, remote 17

Group ID: local 0, remote 0

MTU: local 1500, remote 1500

Remote interface description:

Sequencing: receive disabled, send disabled

VC statistics

packet totals: receive 1146978, send 3856011

byte totals: receive 86579172, send 316899920

packet drops: receive 0, send 0

These examples show the status of the active and backup pseudowires before, during, and after a switchover:

Router# show mpls l2 vc detail

Local intf Local circuit Dest address VC ID Status

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

AT0/2/0.1 ATM VPC CELL 50 10.1.1.2 100 UP

AT0/2/0.1 ATM VPC CELL 50 10.1.1.3 100 STANDBY

 

The show mpls l2 vc detail command on the backup PE router displays the status of the pseudowires as shown in this example. The active pseudowire on the backup PE router has the HOTSTANDBY status.

Router-standby# show mpls l2 vc detail

Local intf Local circuit Dest address VC ID Status

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

AT0/2/0.1 ATM VPC CELL 50 10.1.1.2 100 HOTSTANDBY

AT0/2/0.1 ATM VPC CELL 50 10.1.1.3 100 DOWN

During a switchover, the status of the active and backup pseudowires changes:

Router# show mpls l2 vc detail

Local intf Local circuit Dest address VC ID Status

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

AT0/2/0.1 ATM VPC CELL 50 10.1.1.2 100 RECOVERING

AT0/2/0.1 ATM VPC CELL 50 10.1.1.3 100 DOWN

After the switchover is complete, the recovering pseudowire shows a status of UP:

Router# show mpls l2 vc detail

Local intf Local circuit Dest address VC ID Status

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

AT0/2/0.1 ATM VPC CELL 50 10.1.1.2 100 UP

AT0/2/0.1 ATM VPC CELL 50 10.1.1.3 100 STANDBY

How do I verify whether the LDP neighborship is established between the PE routers?

Use the show mpls ldp neighbor command. This example shows a sample output of the command:

PE1# show mpls ldp neighbor

Peer LDP Ident: 11.11.11.11:0; Local LDP Ident 10.10.10.10:0

TCP connection: 11.11.11.11.32784 - 10.10.10.10.646

State: Oper; Msgs sent/rcvd: 1073/1061; UPstream

Up time: 14:53:49

LDP discovery sources:

GigabitEthernet1/1, Src IP addr: 110.110.110.1

Targeted Hello 10.10.10.10 -> 11.11.11.11, active <<-- This should be 'active'.

Addresses bound to peer LDP Ident:

11.11.11.11 7.23.8.20 120.120.120.2 110.110.110.1

How do I check locally generated LDP PDUs?

Use the show mpls ldp discovery command. This example displays a sample output of the command:

Router# show mpls ldp discovery

Local LDP Identifier:

10.1.1.1:0

Discovery Sources:

Interfaces:

Ethernet1/1/3 (ldp): xmit/recv

LDP Id: 172.23.0.77:0

LDP Id: 10.144.0.44:0

LDP Id: 10.155.0.55:0

ATM3/0.1 (ldp): xmit/recv

LDP Id: 10.203.0.7:2

ATM0/0.2 (tdp): xmit/recv

TDP Id: 10.119.0.1:1

Targeted Hellos:

10.8.1.1 -> 10.133.0.33 (ldp): active, xmit/recv

LDP Id: 10.133.0.33:0

10.8.1.1 -> 192.168.7.16 (tdp): passive, xmit/recv

TDP Id: 10.133.0.33:0Router#

Configuring QoS Features on a SIP

This section describes configuration of the SIP-specific QoS features using the Modular QoS command-line interface (CLI). Before referring to any other QoS documentation for the platform or in the Cisco IOS software, use this section to determine SIP-specific QoS feature support and configuration guidelines.

For additional details about QoS concepts and features in Cisco IOS 12.2 releases, you can then refer to the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2 , at

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

This section includes the following topics:

General QoS Feature Configuration Guidelines

This section identifies some general QoS feature guidelines for certain types of SPAs. You can find other feature-specific SIP and SPA configuration guidelines and restrictions in the other QoS sections of this chapter.

ATM SPA QoS Configuration Guidelines

Follow these guidelines for the 2-Port and 4-Port OC-3c/STM-1 ATM SPA:

  • In the ingress direction, all QoS features are supported by the Cisco 7600 SIP-200.
  • In the egress direction:

All queueing-based features (such as class-based weighted fair queueing [CBWFQ], and ATM per-VC WFQ, WRED, and shaping) are implemented on the segmentation and reassembly (SAR) processor on the SPA.

Policing is implemented on the SIP.

Class queue shaping is not supported.

Effective 15.1(2)S release onwards, all the QoS features for ATM SPA is applicable for CEoP SPA. For more information on configuring QoS Features on CEoP SPAs, see Chapter 11, “Configuring the CEoP and Channelized ATM SPAs”.

Ethernet SPA QoS Configuration Guidelines

For the Ethernet SPAs, the following QoS behavior applies:

  • In both the ingress and egress directions, all QoS features calculate packet size similarly to how packet size calculation is performed by the FlexWAN and Enhanced FlexWAN modules on the Cisco 7600 series router.
  • Specifically, all features consider the IEEE 802.3 Layer 2 headers and the Layer 3 protocol payload. The CRC, interframe gap, and preamble are not included in the packet size calculations.

NoteFor Fast Ethernet SPAs, QoS cannot change the speed of an interface (for example, Fast Ethernet SPAs cannot change QoS settings whenever an interface speed is changed between 100 and 10 Mbps). When the speed is changed, the user must also adjust the QoS setting accordingly.


Configuring QoS Features Using MQC

The Modular QoS CLI (MQC) is a CLI structure that allows users to create traffic policies and attach these policies to interfaces. A traffic policy contains a traffic class and one or more QoS features. A traffic class is used to select traffic, while the QoS features in the traffic policy determine how to treat the classified traffic.

If you apply a traffic policy at a main interface that also contains subinterfaces, then all of the traffic that goes through the subinterfaces is processed according to the policy at the main interface. For example, if you configure a traffic shaping policy at the main interface, all of the traffic going through the subinterfaces is aggregated and shaped to the rate defined in the traffic shaping policy at the main interface.

To configure QoS features using the Modular QoS CLI on the SIPs, complete the following basic steps:


Step 1 Define a traffic class using the class-map command.

Step 2 Create a traffic policy by associating the traffic class with one or more QoS features (using the policy-map command).

Step 3 Attach the traffic policy to the interface using the service-policy command.


 

MQC policy support existing on ATM VC is extended to the ATM PVP from Cisco IOS Release 12.2(33)SRE.

For a complete discussion about MQC, refer to the Modular Quality of Service Command-Line Interface Overview Chapter of the Cisco IOS Quality of Service Solutions Configuration Guide,
Release 12.2
publication at:

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

Configuring QoS Traffic Classes on a SIP

Use the QoS classification features to select your network traffic and categorize it into classes for further QoS processing based on matching certain criteria. The default class, named class-default, is the class to which traffic is directed for any traffic that does not match any of the selection criteria in the configured class maps.

QoS Traffic Class Configuration Guidelines

When configuring traffic classes on a SIP, consider the following guidelines:

  • You can define up to 256 unique class maps.
  • A single class map can contain up to 8 different match command statements.
  • For ATM bridging, Frame Relay bridging, MPB, and BCP features, the following matching features are supported on bridged frames beginning in Cisco IOS Release 12.2(33)SRA:

Matching on ATM CLP bit (input interface only)

Matching on CoS

Matching on Frame Relay DE bit (input interface only)

Matching on Frame Relay DLCI

Matching on inner CoS

Matching on inner VLAN

Matching on IP DSCP

Matching on IP precedence

Matching on VLAN

  • The Cisco 7600 SIP-600 does not support combining matches on QoS group or input VLAN with other types of matching criteria (for example, access control lists [ACLs]) in the same class or policy map.
  • The Cisco 7600 SIP-400 supports matching on ACLs for routed traffic only. Matching on ACLs is not supported for bridged traffic.
  • The SIP-400 does not support dynamic, time-based, or tos-matching ACLs. The SIP-400 also does not support the log option in ACL.
  • When configuring hierarchical QoS on the Cisco 7600 SIP-600, if you configure matching on an input VLAN in a parent policy, then only matching on a QoS group is supported in the child policy.
  • For support of specific matching criteria by SIP, see Table 5-13 .

SUMMARY STEPS


Step 1 class-map [ match-all | match-any ] class-name

Step 2 match type

DETAILED STEPS

To create a user-defined QoS traffic class, use the following commands beginning in global configuration mode:

 

Command
Purpose

Step 1

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

Creates a traffic class, where:

  • match-all —(Optional) Specifies that all match criteria in the class map must be matched, using a logical AND of all matching statements defined under the class. This is the default.
  • match-any —(Optional) Specifies that one or more match criteria must match, using a logical OR of all matching statements defined under the class.
  • class-name —Specifies the user-defined name of the class.

Note You can define up to 256 unique class maps.

Step 2

Router(config-cmap)# match type

Specifies the matching criterion to be applied to the traffic, where type represents one of the forms of the match command supported by the SIP as shown in Table 5-13 .

Note A single class-map can contain up to 8 different match command statements.

Table 5-13 provides information about which QoS classification features are supported for SIPs on the Cisco 7600 series router. For more information about most of the commands documented in this table, refer to the Cisco IOS Quality of Service Solutions Command Reference.

 

Table 5-13 QoS Classification Feature Compatibility by SIP

Feature (match command)
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

Matching on access control list (ACL) number

( match access-group command)

Supported for all SPAs with the following types of ACLs:

  • Protocols—ICMP, IGMP, EIGRP, OSPF, PIM, and GRE
  • Source and destination port
  • TCP flags
  • ToS (DSCP and precedence)

Supported for all SPAs with the following types of ACLs:

  • Source and destination port
  • TCP flag (IPv4 only)
  • IP address (IPv6 compress mode only)

Supported for all SPAs with the following types of ACLs:

  • IPv4 and IPv6
  • Protocols—ICMP, IGMP, UDP, and MAC
  • Source and destination ports
  • TCP flags
  • ToS

Matching on ACL name ( match access-group name command)

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs.

Match on any packet

( match any command)

Note Not supported for user-defined class maps.

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs.

Matching on ATM cell loss priority (CLP) ( match atm clp command)

  • Supported for all ATM SPAs.
  • Cisco IOS Release 12.2(33)SRA—Support added for ATM CLP matching with RFC 1483 bridging features.
  • Supported for all ATM SPAs on ATM input interface only.
  • Cisco IOS Release 12.2(33)SRA—Support added for ATM CLP matching with RFC 1483 bridging features on ATM input interface only.

Not supported.

Matching on class map

( match class-map command)

Supported for all SPAs.

Not supported.

Not supported.

Matching on Class of Service (CoS) ( match cos command)

Supported in Cisco IOS Release 12.2(33)SRA on the 4-Port and 8-Port Fast Ethernet SPA using dot1q encapsulation.

  • Supported on Fast ethernet SPAs from 12.2(33) SRD onwards.
  • 2-Port Gigabit Ethernet SPA only—Input and output 802.1Q tagged frames.
  • Cisco IOS Release 12.2(33)SRA—Support added for inner CoS matching with bridging features.

Supported in Cisco IOS Release 12.2(33)SRA for switchport queueing.

Note CoS classification is available through PFC QoS using MAC address ACLs.

Matching on inner CoS ( match cos inner command)

  • Supported for all SPAs.
  • Cisco IOS Release 12.2(33)SRA—Supported added for inner CoS matching with bridging features.

Supported in Cisco IOS Release 12.2(33)SRA on the 2-Port Gigabit Ethernet SPA and Fast ethernet SPA from 12.2(33) SRD:

  • Input and output interfaces
  • Inner CoS matching with bridging features

Not supported.

Match on Frame Relay discard eligibility (DE) bit ( match fr-de command)

  • Supported for Frame Relay input and output interfaces.
  • Cisco IOS Release 12.2(33)SRA—Support added for Frame Relay DE matching with Frame Relay bridging features.
  • Supported for a Frame Relay input interface only.
  • Cisco IOS Release 12.2(33)SRA—Support added for Frame Relay DE matching with Frame Relay bridging features on input Frame Relay interface only.

Note Because the Cisco 7600 SIP-400 acts as a Frame Relay data terminal equipment (DTE) device only, and not a data communications equipment (DCE) device, the Cisco 7600 SIP-400 does not support dropping of frames that match on FR DE bits; however, other QoS actions are supported.

Not supported.

Match on Frame Relay data-link connection identifier (DLCI) ( match fr-dlci command)

  • Supported for Frame Relay input and output interfaces.
  • Cisco IOS Release 12.2(33)SRA—Support added for Frame Relay DLCI matching with Frame Relay bridging features.

Supported in Cisco IOS Release 12.2(33)SRA on Frame Relay input and output interfaces, and with Frame Relay bridging features.

Not supported.

Match on input VLAN

( match input vlan command—Matches the VLAN from an input interface)

Supported for EoMPLS interfaces.

Supported in Cisco IOS Release 12.2(33)SRA—Output interface only, and with bridging features.

Note Service policy is applied on the output interface of the Cisco 7600 SIP-400 to match the VLAN from the input interface.

Supported in Cisco IOS Release 12.2(33)SRA—Output interface only for software-based EoMPLS.

Note The service policy is applied on the output interface of the Cisco 7600 SIP-600 to match the VLAN from the input interface. If you configure matching on an input VLAN in a parent policy with hierarchical QoS, then only matching on QoS group is supported in the child policy.

Match on IP DSCP ( match ip dscp command)

  • Supported for all SPAs.
  • Cisco IOS Release 12.2(33)SRA—Support added for IP DSCP matching with bridging features on an input interface only.
  • Supported for all SPAs.
  • Cisco IOS Release 12.2(33)SRA—Support added for IP DSCP matching with bridging features.

Supported for all SPAs.

Match on DSCP ( match dscp command)

  • Supported for all SPAs.
  • Supported for all SPAs.
  • Supported for all SPAs.

Match on IP ( match IP command)

  • Supported for all SPAs.
  • Supported for all SPAs.
  • Supported for all SPAs.

Match on IP precedence ( match ip precedence command)

Supported for all SPAs.

  • Supported for all SPAs.
  • Cisco IOS Release 12.2(33)SRA—Support added for IP precedence matching with bridging features.

Supported for all SPAs.

Match on IP Real-Time Protocol (RTP)
( match ip rtp command)

Supported for all SPAs.

Not supported.

Not supported.

Match on MAC address for an ACL name
( match mac address command)

Not supported.

Not supported.

Not supported.

Match on destination MAC address

( match destination-address mac command)

Not supported.

Not supported.

Not supported.

Match on source MAC address

( match source-address mac command)

Not supported.

Not supported.

Not supported.

Match on MPLS experimental (EXP) bit ( match mpls experimental command)

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs.

Match on Layer 3 packet length in IP header ( match packet length command)

Supported for all SPAs.

Not supported.

Not supported.

Match on QoS group ( match qos-group command)

Supported in Cisco IOS Release 12.2(33)SRA—Output interface only.

Not supported.

Supported in software-based EoMPLS configurations only using hierarchical QoS, where the parent policy configures matching on input VLAN and the child policy configures matching on QoS group.

Match on protocol

( match protocol command)

Not supported for NBAR.

Not supported.

Supports matching on IP and IPv6.

Match on VLAN

( match vlan command—Matches the outer VLAN of a Layer 2 802.1Q frame)

Not supported.

Supported in Cisco IOS Release 12.2(33)SRA:

  • Input and output interfaces
  • Outer VLAN ID matching for 802.1Q tagged frames

Supported in Cisco IOS Release 12.2(33)SRA:

  • Output interface only
  • Outer VLAN ID matching for 802.1Q tagged frames

Match on VLAN Inner

( match vlan inner command—Matches the innermost VLAN of the 802.1Q tag in the Layer 2 frame)

  • Supported for all SPAs.
  • Cisco IOS Release 12.2(33)SRA—Support added for inner VLAN ID matching with bridging features.

Supported in Cisco IOS Release 12.2(33)SRA:

  • Input and output interface
  • Inner VLAN ID matching with bridging features

Not supported.

Match ATM VCI

(match atm-vci command)

  • Not supported

Supported on ATM PVP

Not supported

No match on specified criteria

( match not command)

Supported for all SPAs.

Supported for all SPAs.

Not supported.

Configuring QoS Class-Based Marking Policies on a SIP

After you have created your traffic classes, you can configure traffic policies to configure marking features to apply certain actions to the selected traffic in those classes.

In most cases, the purpose of a packet mark is identification. After a packet is marked, downstream devices identify traffic based on the marking and categorize the traffic according to network needs. This categorization occurs when the match commands in the traffic class are configured to identify the packets by the mark (for example, match ip precedence , match ip dscp , match cos , and so on). The traffic policy using this traffic class can then set the appropriate QoS features for the marked traffic.

In some cases, the markings can be used for purposes besides identification. Distributed WRED, for instance, can use the IP precedence, IP DSCP, or MPLS EXP values to detect and drop packets. In ATM networks, the CLP bit of the packet is used to determine the precedence of packets in a congested environment. If congestion occurs in the ATM network, packets with the CLP bit set to 1 are dropped before packets with the CLP bit set to 0. Similarly, the DE bit of a Frame Relay frame is used to determine the priority of a frame in a congested Frame Relay network. In Frame Relay networks, frames with the DE bit set to 1 are dropped before frames with the DE bit set to 0.

QoS Class-Based Marking Policy Configuration Guidelines

When configuring class-based marking on a SIP, consider the following guidelines:

  • Packet marking is supported on interfaces, subinterfaces, and ATM virtual circuits (VCs). In an ATM PVC, you can configure packet marking in the same traffic policy where you configure the queueing actions, on a per-VC basis. However, only PVC configuration of service policies is supported for classes using multipoint bridging (MPB) match criteria.
  • For ATM bridging, Frame Relay bridging, MPB, and BCP features, the following marking features are supported on bridged frames beginning in Cisco IOS Release 12.2(33)SRA:

Set ATM CLP bit (output interface only)

Set Frame Relay DE bit (output interface only)

Set inner CoS

  • If a service policy configures both class-based marking and marking as part of a policing action, then the marking using policing takes precedence over any class-based marking.
  • The Cisco 7600 SIP-600 supports marking on input interfaces only.
  • For support of specific marking criteria by SIP, see Table 5-14 .

SUMMARY STEPS


Step 1 policy-map policy-map-name

Step 2 class class-name | class-default

Step 3 set type

DETAILED STEPS

To configure a QoS traffic policy with class-based marking, use the following commands beginning in global configuration mode:

 

Command
Purpose

Step 1

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

Creates or modifies a traffic policy and enters policy map configuration mode, where:

  • policy-map-name —Specifies the name of the traffic policy to configure. Names can be a maximum of 40 alphanumeric characters.

Step 2

Router (config-pmap)# class class-name | class-default

Specifies the name of the traffic class to which this policy applies and enters policy-map class configuration mode, where:

  • class-name— Specifies that the policy applies to a user-defined class name previously configured.
  • class-default —Specifies that the policy applies to the default traffic class.

Step 3

Router(config-pmap-c)# set type

Specifies the marking action to be applied to the traffic, where type represents one of the forms of the set command supported by the SIP as shown in Table 5-14 .

Table 5-14 provides information about which QoS class-based marking features are supported for SIPs on the Cisco 7600 series router.

 

Table 5-14 QoS Class-Based Marking Feature Compatibility by SIP

Marking Feature (set command)
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

Set ATM CLP bit

( set atm-clp command—Marks the ATM cell loss bit with value of 1)

  • Supported for ATM output interfaces only.
  • Cisco IOS Release 12.2(33)SRA—Support added for ATM CLP marking on output interfaces also with RFC 1483 bridging features.

Supported for ATM SPA output interfaces only.

Not supported.

Set discard class

( set discard-class command—Marks the packet with a discard class value for per-hop behavior)

Not supported.

Not supported.

Not supported.

Set Frame Relay DE bit

( set fr-de command—Marks the Frame Relay discard eligibility bit with value of 1)

  • Supported for Frame Relay output interfaces only.
  • Cisco IOS Release 12.2(33)SRA—Support added for Frame Relay DE marking on output interfaces only with Frame Relay bridging features.

Supported for Frame Relay output interfaces only.

Not supported.

Set DSCP

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs on an input interface.

Set Precedence

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs on an input interface.

Set IP DSCP

( set ip dscp command—Marks the IP differentiated services code point [DSCP] in the type of service [ToS] byte with a value from 0 to 63)

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs on an input interface.

Set IP precedence

( set ip precedence command—Marks the precedence value in the IP header with a value from
0 to 7.)

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs on an input interface.

Set Layer 2 802.1Q CoS

( set cos command—Marks the CoS value from 0 to 7 in an 802.1Q tagged frame)

  • Supported for all SPAs.
  • In Cisco IOS Release 12.2(33)SRA—Not supported with set cos-inner command on the same interface.

Supported in Cisco IOS Release 12.2(33)SRA.

Not supported.

Set Layer 2 802.1Q CoS

( set cos-inner command—Marks the inner CoS field from 0 to 7 in a bridged frame)

Supported in Cisco IOS Release 12.2(33)SRA with bridging features on the 4-Port and 8-Port Fast Ethernet SPA.

Supported in Cisco IOS Release 12.2(33)SRA with bridging features.

Not supported.

Set MPLS experimental (EXP) bit on label imposition

( set mpls experimental imposition command)

Supported for all SPAs.

Supported for all SPAs.

Note The table keyword is not supported.

Supported for all SPAs on an input interface.

Set MPLS EXP on topmost MPLS label

( set mpls experimental topmost command)

Supported for all SPAs.

Supported for all SPAs.

Not supported.

Set QoS group

( set qos-group command—Marks the packet with a QoS group association)

Not supported.

Not supported.

Supported only for software-based EoMPLS on an input SPA switchport interface.

For more detailed information about configuring class-based marking features, refer to the Class-Based Marking document located at the following URL:

http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/cbpmark2.html


NoteWhen referring to other class-based marking documentation, be sure to note any SIP-specific configuration guidelines described in this document.


Configuring QoS Congestion Management and Avoidance Policies on a SIP

This section describes SIP- and SPA-specific information for configuring QoS traffic policies for congestion management and avoidance features. These features are generally referred to as queueing features.

QoS Congestion Management and Avoidance Policy Configuration Guidelines

When configuring queueing features on a SIP, consider the following guidelines:

  • The Cisco 7600 series router supports different forms of queueing features. See Table 5-15 to determine which queueing features are supported by SIP type.
  • When configuring queueing on the Cisco 7600 SIP-400, consider the following guidelines:

A queue on the Cisco 7600 SIP-400 is not assured any minimum bandwidth.

You cannot configure bandwidth or shaping with queueing under the same class in a service policy on the Cisco 7600 SIP-400.

If you want to define bandwidth parameters and priority under different classes in the same service policy on the Cisco 7600 SIP-400, then you can only use the bandwidth remaining percent command. The Cisco 7600 SIP-400 does not support other forms of the bandwidth command with priority in the same service policy.

  • You can use policing with queueing to limit the traffic rate.
  • On the Cisco 7600 SIP-400, WRED is supported on bridged VCs with classification on precedence and DSCP values. On other SIPs, WRED does not work on bridged VCs (for example, VCs that implement MPB).
  • When configuring WRED on the Cisco 7600 SIP-400, consider the following guidelines:

WRED is supported on bridged VCs with classification on precedence and DSCP values.

WRED explicit congestion notification (ECN) is not supported for output traffic on ATM SPAs.

ECN is supported for IP traffic on output POS interfaces only.

You can use the low-order TOS bits in the IP header for explicit congestion notification (ECN) for WRED. If you configure random-detect ecn in a service policy and apply it to either a POS interface or a VC on a POS interface, then if at least one of the ECN bits is set and the packet is a candidate for dropping, the Cisco 7600 SIP-400 marks both ECN bits. If either one of the ECN bits is set, the Cisco 7600 SIP-400 will not drop the packet.

WRED ECN is not support for MPLS packets.

  • On the Cisco 7600 SIP-400, the default queue limit is calculated on the following basis:

As of Cisco IOS 12.2(33) SRB Release, the default queue limit is calculated based on the number of 250-byte packets that the SIP can transmit in one half of a second. For example, for an OC-3 SPA with a rate of 155 Mbps, the default queue limit is 38,750 packets (155000000 x 0.5 / 250 x 8). As of Cisco IOS 12.2(33)SRB Release, configurable values for queue-limit and WRED thresholds are in units of 250-byte buffers when configuring these parameters on a SIP-400.

When configured in Cisco IOS 12.2(33) SXF Release and Cisco IOS 12.2(33)SRA Release, the configured queue-limit and WRED thresholds on the SIP-400 are in units of packets, regardless of the packet size.

  • For more detailed information about configuring congestion management features, refer to the Cisco IOS Quality of Service Solutions Configuration Guide document corresponding to your Cisco IOS software release .

Table 5-15 provides information about which QoS queueing features are supported for SIPs on the Cisco 7600 series router.


NoteEffective with Cisco IOS Release 15.0(1)S, the fair-queue (WFQ) command is not available on Cisco IOS Software. Use the MQC equivalent fair-queue (WFQ) command in 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


 

Table 5-15 QoS Congestion Management and Avoidance Feature Compatibility by SIP and SPA Combination

Congestion Management and Avoidance Feature
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

Aggregate Weighted Random Early Detection

( random-detect aggregate , random-detect dscp (aggregate) , and random-detect precedence (aggregate) commands)

Supported for ATM SPA PVCs only—Cisco IOS Release 12.2(18)SXE and later and in Cisco IOS Release 12.2(33)SRA

Supported for ATM SPA PVCs only—Cisco IOS Release 12.2(18)SXE and later and in Cisco IOS Release 12.2(33)SRA.

Supported for all SPAs.

For more information on configuring aggregate WRED, see the “Configuring Aggregate WRED for PVCs” section.

Class-based Weighted Fair Queueing (CBWFQ)

( bandwidth , queue-limit commands)

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs.

Dual-Queue Support

( priority and priority level commands)

Not supported.

Supported for all SPAs—Cisco IOS Release 12.2(33)SRB and later.

Not supported.

Flow-based Queueing (fair queueing/WFQ)

( fair-queue command)

Supported for all SPAs.

Not supported.

Not supported.

Low Latency Queueing (LLQ)/ Queueing

( priority command)

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs.

Random Early Detection (RED)

( random-detect commands)

Supported for all SPAs.

  • ATM SPAs—Up to 106 unique WRED minimum threshold (min-th), maximum threshold (max-th), and mark probability profiles supported.
  • Other SPAs—Up to 128 unique WRED min-th, max-th, and mark probability profiles supported.

Supported for all SPAs.

  • ATM SPAs—Up to 106 unique WRED minimum threshold (min-th), maximum threshold (max-th), and mark probability profiles supported.
  • Other SPAs—Up to 128 unique WRED min-th, max-th, and mark probability profiles supported.

Not supported.

Weighted RED (WRED)

Supported for all SPAs, with the following exception:

  • WRED is not supported on bridged VCs.

Supported for all SPAs, with the following restriction:

  • WRED is supported on bridged VCs with classification on precedence and DSCP values.

Not supported.

Priority percent on Policy Map

Supported

Note Priority percent is not supported in ATM SPAs for both SIP200 and SIP400.

Supported

Note Priority percent is not supported in ATM SPAs for both SIP200 and SIP400.

Not Supported

All QoS features in ingress

Supported

Supported

Supported

Strict priorityand Ingress, no queueing

Supported

Supported

Supported

Policing, classification, policing and marking in egress

Supported

Supported

Supported

Oversubscription

Supported

Supported

Note In Cisco IOS 12.2(33)SRB Release, oversubscription is only supported for two 2-Port Copper and Optical Gigabit Ethernet SPAs.

Note In the Cisco IOS 12.2(33)SRC Release support for oversubscription is extended to the 1-Port 10-Gigabit Ethernet SPA. Ingress oversubscription is only supported on Ethernet SPAs.

Note Cisco IOS 12.2(33)SRC Release supports the following specific SPA combinations:

Any combination of POS, ATM, CEoPs, and serial or channelized SPAs up to OC-48 aggregate bandwidth

One 2-Port Gigabit Ethernet SPA or 2-Port Copper and Optical Gigabit Ethernet SPA and up to OC-24 equivalents of POS, ATM, CEoPs, and serial or channelized SPAs.

One2-Port Copper and Optical Gigabit Ethernet SPA or two 2-Port 5GEv2 SPAs. (These are the ingress oversubscription combinations. This is the only case where the SIP-400 is oversubscribed on ingress.

Supported

SUMMARY STEPS


Step 1 policy-map policy-map-name

Step 2 class class-name | class-default

Step 3 bandwidth bandwidth-kbps | percent percent

Step 4 queue-limit number-of-packets

DETAILED STEPS

To configure a QoS CBWFQ policy, use the following commands beginning in global configuration mode:

 

Command
Purpose

Step 1

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

Creates or modifies a traffic policy and enters policy map configuration mode, where:

  • policy-map-name —Specifies the name of the traffic policy to configure. Names can be a maximum of 40 alphanumeric characters.

Step 2

Router (config-pmap)# class class-name | class-default

Specifies the name of the traffic class to which this policy applies and enters policy-map class configuration mode, where:

  • class-name— Specifies that the policy applies to a user-defined class name previously configured.
  • class-default —Specifies that the policy applies to the default traffic class.

Step 3

Router(config-pmap-c)# bandwidth bandwidth-kbps | percent percent

Specifies the bandwidth allocated to a class belonging to a policy map.

Note The amount of bandwidth configured should be large enough to also accommodate Layer 2 overhead.

  • bandwidth-kbps —Specifies the amount of bandwidth, in number of kbps, to be assigned to a class.
  • percent —Specifies the amount of guaranteed bandwidth, based on the absolute percent of available bandwidth.
  • percentage —Used in conjunction with the percent keyword, the percentage of the total available bandwidth to be set aside for the priority classes.

Note If strict priority is assigned to a class in the parent policy, and control packets do not fall in that class, the interface may flap between the UP and DOWN states as the strict priority consumes the entire bandwidth .
See Sample Configuration Scenario, page 110 for a sample scenaio illustrating this effect.

Step 4

Router(config-pmap-c)# queue-limit number-of-packets

Specifies the maximum number of packets the queue can hold for a class policy configured in a policy map.

  • number-of-packets —A number in the range 1-65536 specifying the maximum number of packets that the queue for this class can accumulate.

Sample Configuration Scenario

Router#show policy-map interface
GigabitEthernet3/3/0
 
Service-policy output: policy_map_1
Counters last updated 00:00:02 ago
queue stats for all priority classes:
Queueing
queue limit 25000 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
 
Class-map: classmap_1 (match-all)
 
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: ip precedence 1
Priority: Strict, b/w exceed drops: 0
 

Strict priority

Class-map: class-default (match-any)
4 packets, 240 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
queue limit 2 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 4/240
Router#
 
Router#
 
 
Router#show policy-map interface
GigabitEthernet3/3/0
 
Service-policy output: policy_map_1
 
Counters last updated 00:00:02 ago
 
queue stats for all priority classes:
Queueing
queue limit 25000 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
 
Class-map: classmap_1 (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: ip precedence 1
Priority: Strict, b/w exceed drops: 0


Strict priority

 
Class-map: class-default (match-any)
4 packets, 240 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
queue limit 2 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 4/240
Router#
 
 
Router#show interface GigabitEthernet3/3/0
GigabitEthernet3/3/0 is up, line protocol is up
Hardware is GigEther SPA, address is 0023.33c5.dc40 (bia 0023.33c5.dc40)
Internet address is 9.30.65.47/16
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

BW=100000 kbps (interface bandwidth)

reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not supported
Full Duplex, 100Mbps, media type is T
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/274/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
5 minute input rate 2000 bits/sec, 4 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
983112 packets input, 71000650 bytes, 0 no buffer
Received 73032 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
274 input errors, 17 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 514955 multicast, 0 pause input
6856 packets output, 519181 bytes, 0 underruns
0 output errors, 0 collisions, 4 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out Router#
 
Router#
 

Configuring Dual-Priority Queuing on a Cisco 7600 SIP-400

When configuring Dual-Priority Queuing, consider the following guidelines:

  • Only two priority levels are supported.
  • Level 1 is higher than level 2.
  • Propagation is supported on both levels.
  • A priority without a level is mapped to level 1.
  • The police rate includes a Layer 2 header but not cyclic redundancy check (CRC), preamble, or interframe gap.
  • Dual-priority queuing is not supported on ATM SPAs.

 

SUMMARY STEPS


Step 1 priority

Step 2 priority leve

Step 3 priority y ms

Step 4 priority x kbps y bytes

Step 5 priority percent x% | y ms

DETAILED STEPS

To configure dual-priority queuing, use the following commands:

Command or Action
Purpose

Router(config-pmap-c)# priority

Gives priority to a class of traffic belonging to a policy map.

Router(config-pmap-c)# priority level

Configures multiple priority queues.

  • level —A range of priority levels. Valid values are from 1 (high priority) to 4 (low priority). The default is 1.

Router(config-pmap-c)# priority y ms

  • ms —Specifies the burst size in bytes. The burst size configures the network to accommodate temporary bursts of traffic.

Router(config-pmap-c)# priority x kbps y bytes

  • x kbps— Specifies the burst size in kbps.
  • y bytes— Specifies the burst size in bytes.

Router(config-pmap-c)# priority percent x% | y ms

Enables conditional policing rate (kbps or link percent). Conditional policing is used if the logical or physical link is congested.

Configuring Hierarchical Queuing Framework on a Cisco 7600 SIP-400

Hierarchical Queuing Framework configuration involves two modules residing on the SIP-400 line card - the HQF client and the HQF mapper functions. The HQF client processes requests from the mapper. The role of the mapper module is primarily to create, update, and delete queues. While configuring the HQF, use the following guidelines:

  • Only two priority levels are supported.
  • Level 1 is higher than level 2.
  • Propagation is supported on both levels.
  • A priority without a level is mapped to level 1.
  • The sum of bandwidth percentage and another queue’s bandwidth reservation must not exceed 100% bandwidth.
  • The police rate includes a Layer 2 header but not cyclic redundancy check (CRC), preamble, or interframe gap.
  • Dual-priority queuing is not supported on ATM SPAs.

SUMMARY STEPS


Step 1 policy-map policy-name

Step 2 class class-name

Step 3 priority y ms

Step 4 priority x kbps y bytes

Step 5 priority percent x% | y ms

Step 6 police rate

DETAILED STEPS

To configure dual-priority queuing, use the following commands:

 

Command or Action
Purpose

Router(config)# policy-map policy-name

Specifies the name of the policy map to be created or modified.

Router(config-pmap)# class class-name

  • Specifies the name of a predefined class included in the service policy.

Router(config-pmap-c)# priority y ms

  • ms —Specifies the burst size in bytes. The burst size configures the network to accommodate temporary bursts of traffic.

Router(config-pmap-c)# priority x kbps y bytes

  • x kbps— Specifies the burst size in kbps.
  • y bytes— Specifies the burst size in bytes.

Router(config-pmap-c)# priority percent x% | y ms

Enables conditional policing rate (kbps or link percent). Conditional policing is used if the logical or physical link is congested.

Router(config-pmap-c)# police rate

Sets the policing rate (in bps)

Configuring Priority Percent on a Policy-Map on a Cisco 7600 SIP-400

SUMMARY STEPS


Step 1 class-map name

Step 2 match ip precedence 0-7

Step 3 policy-map name

Step 4 class voip

Step 5 priority percent 1-100

DETAILED STEPS

To configure priority percent on a policy-map, use the following commands:

 

Command or Action
Purpose

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

Example:

Router(config-pmap-c)# class-map voip

Specifies a class belonging to a policy map.

Router(config-pmap-c)# match ip precedence 0-7

Example:

Router(config-pmap-c)# match ip precedence 3

Matches the precedence value in the IP header with a value from 0 to 7.

Router(config-pmap-c)# policy-map name

Example:

Router(config-pmap-c)# policy-map llq

Specifies the name of the policy map.

Router(config-pmap-c)# class name

Example:

Router(config-pmap-c)# class voip

Specifies the traffic class to which the policy applies

Router(config-pmap-c)# priority percent 1-100

Example:

Router(config-pmap-c)# priority percent 23

Enables specified conditional policing rate on the policy map


NoteQueuing for QoS features like CBWFQ, LLQ, WRED, happens on the ATM-SPA itself (SPA-ATM-OC3/OC12/OC48 on SIP200/SIP400). Because of hardware limitations, a policy-map with priority percent, can not work on SPA-ATM-OC3/OC12/OC48.
So while configuring dLFIoATM on SPA-ATM-OC3/OC12/OC48 on SIP200/SIP400, a Virtual-Template interface configured with a policy-map having priority percent command can not be associated to a PVC


Configuring Percent Priority and Percent Bandwidth Support on a Cisco 7600 SIP-400

SUMMARY STEPS


Step 1 bandwidth x kbps

Step 2 bandwidth percent x%

Step 3 bandwidth remaining percent x%

DETAILED STEPS

To configure percent priority and percent bandwidth, use the following commands:

 

Command or Action
Purpose

Router(config-pmap-c)# bandwidth x kbps

Specifies or modifies the bandwidth allocated for a class belonging to a policy map.

Router(config-pmap-c)# bandwidth percent x%

Specifies the amount of guaranteed bandwidth, based on an absolute percent of available bandwidth.

Router(config-pmap-c)# bandwidth remaining percent x%

Specifies the remaining percent— Amount of guaranteed bandwidth, based on a relative percent of available bandwidth.

Ingress HQF on Cisco 7600 SIP-400

Ingress Hierarchical Queueing Framework (HQF) feature is implemented to provide bandwidth guarantee for classes of traffic in ingress direction on the SIP-400 and to ensure effective utilization of interface bandwidth. Traffic in a class should be able to use all the available parent bandwidth, but should be restricted to the bandwidth allocated to the class during congestion.

As part of the ingress HQF, bandwidth, priority, queue-limit, and shaper queuing features are supported on SIP-400 in ingress direction. Using ingress HQF, you can restrict the incoming traffic to lesser than the interface bandwidth through a parent shaper and also ensure that traffic in each class gets the allocated share of the available bandwidth when the aggregate incoming traffic exceeds or equals the parent shaper.

Restrictions for Ingress HQF

These restrictions apply to the ingress HQF on Cisco 7600 SIP-400.

  • Weighted Random Early Detection (WRED), Multilink Frame Relay (MFR) and Multilink Point-to-Point Protocol (MLPPP) are not supported.
  • Ingress HQF features (except shaping) are supported only on physical interfaces.
  • Shaping is already supported on ethernet interfaces, sub interfaces and EVCs and it is extended to non ethernet interfaces as part of the ingress HQF feature.
  • Priority should be configured with explicit policer. The priority kbps and priority percent commands, which use a conditional policer, are not supported.
  • The following QoS features are supported:

Bandwidth

Bandwidth kbps

Bandwidth percent

Bandwidth remaining ratio

Bandwidth remaining percent

Priority level and unconditional policer

Strict priority

Shape average kbps

Queue-limit

  • These SPAs are not supported:

2-Port and 4-Port OC-3c/STM-1 ATM SPAs

1-Port OC-12c/STM-4 ATM SPA

1-Port OC-48c/STM-16 ATM SPA

1-Port and 3-port Clear Channel OC-3 ATM SPA Version 2

1-Port Clear Channel OC-12 ATM SPA Version 2


NoteIngress control packets need to be classified and bandwidth should be reserved to protect such traffic. Otherwise, the ingress control packets can be subjected to QoS and may get tail dropped.


Configuring Ingress HQF on Cisco 7600 SIP-400

Perform these steps to configure ingress HQF for a class belonging to a policy map using bandwidth allocation commands.

SUMMARY STEPS


Step 1 enable

Step 2 configure terminal

Step 3 policy-map policy-map-child

Step 4 class { class-name | class-default}

Step 5 bandwidth { bandwidth-kbps | remaining percent percentage | percent percentage }

Step 6 exit

Step 7 exit

Step 8 policy-map policy-map-parent

Step 9 class { class-name | class-default}

Step 10 shape average cir [bc] [be]

Step 11 service-policy policy-map-child

Step 12 exit

DETAILED STEPS

 

Command or Action
Purpose

enable

Example:

Router# enable

Enables privileged EXEC mode. Enter your password if prompted.

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

policy-map policy-map-child

Example:

Router(config)# policy-map child

Specifies the name of the child policy map to be created.

class { class-name | class-default }

Example:

Router(config-pmap)# class class1

Specifies the name of the traffic class to which this policy applies and enters policy-map class configuration mode, where:

  • class-name— Specifies that the policy applies to a user-defined class name previously configured.
  • class-default —Specifies that the policy applies to the default traffic class.

bandwidth { bandwidth-kbps | remaining percent percentage | percent percentage }

Example:

Router(config-pmap-c)# bandwidth percent 20

Specifies or modifies the bandwidth allocated for a class belonging to a policy map.

  • bandwidth-kbps- Amount of bandwidth, in kilobytes per second (kbps), to be assigned to the class. The amount of bandwidth varies according to the interface and platform in use.
  • remaining percent - Specifies the amount of guaranteed bandwidth, based on a relative percent of available bandwidth.
  • percent - Specifies the amount of guaranteed bandwidth, based on a absolute percent of available bandwidth.

exit

Example:

Router(config-pmap-c)# exit

Exits the class map configuration.

exit

Example:

Router(config-pmap)# exit

Exits the child policy map configuration.

policy-map policy-map-parent

Example:

Router(config)# policy-map parent

Specifies the name of the child policy map to be created.

class { class-name | class-default }

Example:

Router(config-pmap)# class class-default

Specifies the name of the traffic class to which this policy applies and enters policy-map class configuration mode, where:

  • class-name— Specifies that the policy applies to a user-defined class name previously configured.
  • class-default —Specifies that the policy applies to the default traffic class.

shape average cir [ bc ] [ be ]

Example:

Router(config-pmap-c)# shape average 10000000

Specifies average or peak rate traffic shaping.

  • cir— Specifies the committed information rate (CIR), in bits per second (bps).
  • bc— (Optional) Specifies the Committed Burst size, in bits.
  • be— (Optional) Specifies the Excess Burst size, in bits.

service-policy policy-map-child

Example:

Router(config-pmap-c)# service-policy child

Attaches the child policy-map to a class.

exit

Example:

Router(config-pmap-c)# exit

Exits from class-map configuration mode.

exit

Example:

Router(config-pmap)# exit

Exits from policy-map configuration mode.

Configuration Example for Ingress HQF

This example shows how to configure ingress HQF for user defined classes using bandwidth allocation commands.

Router# enable
Router# configure terminal
Router(config)# class-map match-any queue1
Router(config-cmap)# match precedence 0
Router(config-cmap)# exit
Router(config)# class-map match-any queue2
Router(config-cmap)# match precedence 1
Router(config-cmap)# exit
Router(config)# policy-map child
Router(config-pmap)# class queue1
Router(config-pmap-c)# bandwidth remaining percent 10
Router(config-pmap-c)# exit
Router(config-pmap)# class queue2
Router(config-pmap-c)# bandwidth remaining percent 20
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# policy-map parent
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 120000000
Router(config-pmap-c)# service-policy child
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface gigabitEthernet 1/2
Router(config-if)# service-policy input parent
Router(config-if)# exit
Router(config)# exit

 

This example shows how to configure ingress HQF for user defined classes using bandwidth allocation and multi-level priority queuing.

Router# enable
Router# configure terminal
Router(config)# class-map match-any queue1
Router(config-cmap)# match precedence 0
Router(config-cmap)# exit
Router(config)# class-map match-any queue2
Router(config-cmap)# match precedence 1
Router(config-cmap)# exit
Router(config)# class-map match-any queue3
Router(config-cmap)# match precedence 2
Router(config-cmap)# exit
Router(config)# policy-map child
Router(config-pmap)# class queue1
Router(config-pmap-c)# priority level 1
Router(config-pmap-c)# police cir 80000
Router(config-pmap-c)# exit
Router(config-pmap)# class queue2
Router(config-pmap-c)# priority level 2
Router(config-pmap-c)# police cir 120000
Router(config-pmap-c)# exit
Router(config-pmap)# class queue3
Router(config-pmap-c)# bandwidth remaining percent 15
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# policy-map parent
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 120000000
Router(config-pmap-c)# service-policy child
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface gigabitEthernet 1/2
Router(config-if)# service-policy input parent
Router(config-if)# exit
Router(config)# exit

This example shows how to configure ingress HQF for user defined classes using bandwidth allocation and queue limit.

Router# enable
Router# configure terminal
Router(config)# policy-map child
Router(config-pmap)# class queue1
Router(config-pmap-c)# bandwidth 30000
Router(config-pmap-c)# queue-limit 40
Router(config-pmap-c)# exit
Router(config-pmap)# class queue2
Router(config-pmap-c)# bandwidth 20000
Router(config-pmap-c)# exit
Router(config)# policy-map parent
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 120000000
Router(config-pmap-c)# service-policy child
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface gigabitEthernet 1/1
Router(config-if)# service-policy input parent
Router(config-if)# exit
Router(config)# exit

This example shows how to configure ingress HQF using a 3 level hierarchical policy. In this policy, queuing is configured on parent and child policies but not on grand child policies.

Router# enable
Router# configure terminal
Router(config)# class-map match-any prec0
Router(config-cmap)# match precedence 0
Router(config-cmap)# exit
Router(config)# class-map match-any prec1
Router(config-cmap)# match precedence 1
Router(config-cmap)# exit
Router(config)# class-map match-any prec2
Router(config-cmap)# match precedence 2
Router(config-cmap)# exit
Router(config)# class-map match-any prec3
Router(config-cmap)# match precedence 3
Router(config-cmap)# exit
Router(config)# class-map match-any dscp
Router(config-cmap)# match ip dscp 10
Router(config-cmap)# exit
Router(config)# policy-map grand-child
Router(config-pmap)# class dscp
Router(config-pmap-c)# police 100000
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# policy-map child
Router(config-pmap)# class prec0
Router(config-pmap-c)# bandwidth percent 10
Router(config-pmap-c)# queue-limit 1000
Router(config-pmap-c)# service-policy grand-child
Router(config-pmap-c)# exit
Router(config-pmap)# class prec1
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap-c)# queue-limit 2000
Router(config-pmap-c)# service-policy grand-child
Router(config-pmap-c)# exit
Router(config-pmap)# class prec2
Router(config-pmap-c)# bandwidth percent 30
Router(config-pmap-c)# queue-limit 3000
Router(config-pmap-c)# exit
Router(config-pmap)# class prec3
Router(config-pmap-c)# bandwidth percent 40
Router(config-pmap-c)# queue-limit 4000
Router(config-pmap-c)# service-policy grand-child
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# policy-map parent
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 120000000
Router(config-pmap-c)# service-policy child

Router(config-pmap-c)# exit

Router(config-pmap)# exit
Router(config)# interface gigabitEthernet 1/1
Router(config-if)# service-policy input parent
Router(config-if)# exit
Router(config)# exit

 

Verifying Ingress HQF

Use these show commands to verify the ingress HQF support configuration.

Command
Purpose

show policy-map

Displays the configuration of all classes for a specified service policy map or all classes for all existing policy maps.

show policy-map interface

Displays the configuration of all classes configured for all service policies on the specified interface.

Configuring QoS Traffic Shaping Policies on a SIP

This section describes SIP- and SPA-specific information for configuring QoS traffic policies for shaping traffic.

QoS Traffic Shaping Policy Configuration Guidelines

When configuring queueing features on a SIP, consider the following guidelines:

  • The Cisco 7600 series router supports different forms of queueing features. See Table 5-16 to determine which traffic shaping features are supported by SIP type.
  • Use a hierarchical policy if you want to achieve minimum bandwidth guarantees using CBWFQ with a Frame Relay map class. First, configure a parent policy to shape to the total bandwidth required (on the Cisco 7600 SIP-400, use the class-default in Cisco IOS Release 12.2(18)SXF, or a user-defined class beginning in Cisco IOS Release 12.2(33)SRA). Then, define a child policy using CBWFQ for the minimum bandwidth percentages.
  • ATM SPAs do not support MQC-based traffic shaping. You need to configure traffic shaping for ATM interfaces using ATM Layer 2 VC shaping.
  • For more detailed information about configuring congestion management features, refer to the Cisco IOS Quality of Service Solutions Configuration Guide document corresponding to your Cisco IOS software release .

NoteIn case of SIP 600 with Cisco 7600 router where traffic shaping is configured, while calculating overhead for traffic shaping the frame check sequence (FCS), inter frame gap (IFG), and preamble bytes are also counted by the Cisco 7600 router except the configuration when user-defined value is zero. If shaping is configured and user-defined value is configured as zero the over head is calculated the same way as SIP 400 where the 14 byte ethernet header and any VLAN headers are counted in shaper or policer by default. If policer is configured with SIP 600, the over head calulation is not changed by user-defined value zero.


Table 5-16 provides information about which QoS traffic shaping features are supported for SIPs on the Cisco 7600 series router.

 

Table 5-16 QoS Traffic Shaping Feature Compatibility by SIP and SPA Combination

Traffic Shaping Feature (shape command)
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

Adaptive shaping for Frame Relay

( shape adaptive command)

Supported for all SPAs.

Not supported.

Not supported.

Class-based shaping

( shape average , shape peak commands)

Supported for all SPAs.

Shape average is supported for all SPAs with the following exceptions:

  • Committed burst (bc)—Not supported.
  • Excess burst (be)—Not supported.

Supports only shape average for all SPAs.

Policy-map class shaping of average-rate of traffic by percentage of bandwidth

( shape average percent command )

Not supported.

Not supported.

Not supported.

Policy-map class shaping with adaptation to backward explicit congestion notification (BECN)

( shape adaptive command)

Supported for all SPAs.

Not supported.

Not supported.

Policy-map class shaping with reflection of forward explicit congestion notification (FECN) as BECN

( shape fecn-adapt command)

Supported for all SPAs.

Not supported.

Not supported.

Policy-map class shaping of peak-rate of traffic by percentage of bandwidth

( shape peak percent command)

Not supported.

Not supported.

Not supported.

 

Configuring QoS Traffic Policing Policies on a SIP

This section describes SIP- and SPA-specific information for configuring QoS traffic policing policies.

QoS Traffic Policing Policy Configuration Guidelines

When configuring traffic policing on a SIP, consider the following guidelines:

  • The Cisco 7600 series router supports different forms of policing using the police command. See Table 5-17 to determine which policing features are supported by SIP type.
  • When configuring policing on the Cisco 7600 SIP-600, consider the following guidelines:

The Cisco 7600 SIP-600 supports conform-action policing on input interfaces only, unless it is being implemented with queueing.

The Cisco 7600 SIP-600 does not support any policing actions (shown in Table 5-18 ) using the exceed-action or violate-action keywords on an input interface.

The Cisco 7600 SIP-600 supports exceed-action policing on an output interface with a drop action only, when the policing is being implemented with queueing.

The Cisco 7600 SIP-600 supports marking for exceed-action policing only using the set-dscp-transmit command.

  • When configuring a policing service policy and specifying the CIR in bits per second without specifying the optional conform (bc) or peak (be) burst in bytes, the Cisco 7600 SIP-400 calculates the burst size based on the number of bytes that it can transmit in 250 ms using the CIR value.

    For example, a CIR of 1 Mbps (or 1,000,000 bps) is equivalent to 125,000 bytes per second, which is 125 bytes per millisecond.
    The calculated burst is 250 x 125 = 31250 bytes. If the calculated burst is less than the interface maximum transmission unit (MTU), then the interface MTU is used as the burst size.

This behavior remains till SRE Release. From Release 15.0(1)S onwards, if the calculated burst size is less than the MTU, SIP 400 will not increment the burst size to the MTU.

  • You can use policing with queueing to limit the traffic rate.
  • If a service policy configures both class-based marking and marking as part of a policing action, then the marking using policing takes precedence over any class-based marking.
  • When configuring policing with MPB features on the Cisco 7600 SIP-200 and Cisco 7600 SIP-400, the set-cos-inner-transmit action is supported beginning in Cisco IOS Release 12.2(33)SRA.
  • SIP-400 line cards do not support multiple marking actions in one police class of traffic. For example - set-cos-inner-transmit and set-cos-transmit both cannot be configured together as below:
    class accPriority
    priority
    police cir percent 40 pir percent 100
    conform-action set-cos-inner-transmit 5
    conform-action set-cos-transmit 5
  • Set-mpls-experimental-topmost-transmit command configuration guidelines on SIP-400.
    Refer Table 5-18 for QoS Policing Action Compatibility by SIP and SPA Combination .
    The set-mpls-experimental-topmost-transmit is valid for ingress side only. The set-mpls-experimental-topmost-transmit command is only effective when the SIP-400 receives a packet from line with the MPLS tag. The set-mpls-experimental-imposition-transmit is effective when the imposition is done on the ingress side.
    If SIP-400 does the imposition it inserts the EXPERIMENTAL bit(s) directly otherwise it copies the EXP bit to DBUS COS. EARL will then copy the DBUS COS to EXP while doing the imposition. This is expected behaviour. So even though set-mpls-experimental-topmost-transmit is supported on SIP-400, it works differently in the L3VPN case where the packet coming in from line is not an MPLS tagged packet.

NoteFor any policer command, the minimum policer configuration value is 8kbps.


Table 5-17 provides information about which policing features are supported for SIPs on the Cisco 7600 series router.

 

Table 5-17 QoS Policing Feature Compatibility by SIP and SPA Combination

Policing Feature (police command)
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

Policing by aggregate policer

( police aggregate command)

Not supported.

Not supported.

Supported for all SPAs.

Policing by bandwidth using token bucket algorithm

( police command)

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAS.

Policing by committed information rate (CIR) percentage

( police (percent) command— police cir percent form)

Supported for all SPAs.

Supported for all SPAs.

Not supported.

Policing with 2-color marker (CIR and peak information rate [PIR])

( police (two rates) command— police cir pir form)

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs.

Policing by flow mask

( police flow mask command)

Not supported.

Not supported.

Supported for all SPAs.

Policing by microflow

( police flow command)

Not supported.

Not supported.

Supported for all SPAs.

To create QoS traffic policies with policing, use the following commands beginning in global configuration mode:

 

Command
Purpose

Step 1

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

Creates or modifies a traffic policy and enters policy map configuration mode, where:

  • policy-map-name —Specifies the name of the traffic policy to configure. Names can be a maximum of 40 alphanumeric characters.

Step 2

Router (config-pmap)# class { class-name | class-default }

Specifies the name of the traffic class to which this policy applies and enters policy-map class configuration mode, where:

  • class-name— Specifies that the policy applies to a user-defined class name previously configured.
  • class-default —Specifies that the policy applies to the default traffic class.

Use one of the following forms of police commands to evaluate traffic for the specified class. See Table 5-17 to determine which SIPs support the different policing features.

Step 3

Router(config-pmap-c)# police bps [ burst-normal ] [ burst-max ] conform-action action exceed-action action violate-action action

Specifies a maximum bandwidth usage by a traffic class through the use of a token bucket algorithm, where:

  • bps —Specifies the average rate in bits per second. Valid values are 8000 to 200000000.
  • burst-normal— (Optional) Specifies the normal burst size in bytes. Valid values are 1000 to 51200000. The default normal burst size is 1500 bytes.
  • burst-max— (Optional) Specifies the excess burst size in bytes. Valid values are 1000 to 51200000.
  • action— Specifies the policing command (as shown in Table 5-18 ) for the action to be applied to the corresponding conforming, exceeding, or violating traffic.

Step 4

Router(config-pmap-c)# police cir percent percentage [ burst-in-msec ] [ bc conform-burst-in-msec ] [ pir percent percentage ] [ be peak-burst-in-msec ] [ conform-action action [ exceed-action action [ violate-action action ]]]

Configures traffic policing on the basis of a percentage of bandwidth available on an interface, where:

  • cir percent percentage— Specifies the committed information rate (CIR) bandwidth percentage. Valid values are 1 to 100.
  • burst-in-msec— (Optional) Burst in milliseconds. Valid values are 1 to 2000.
  • bc conform-burst-in-msec— (Optional) Specifies the conform burst (bc) size used by the first token bucket for policing traffic in milliseconds. Valid values are
    1 to 2000.
  • pir percent percentage— (Optional) Specifies the peak information rate (PIR) bandwidth percentage. Valid values are 1 to 100.
  • be peak-burst-in-msec— (Optional) Specifies the peak burst (be) size used by the second token bucket for policing traffic in milliseconds. Valid values are 1 to 2000.
  • action— Specifies the policing command (as shown in Table 5-18 ) for the action to be applied to the corresponding conforming, exceeding, or violating traffic.

Step 5

Router(config-pmap-c)# police { cir cir } [ bc conform-burst ] { pir pir } [ be peak-burst ] [ conform-action action [ exceed-action action [ violate-action action ]]]

Configures traffic policing using two rates, the committed information rate (CIR) and the peak information rate (PIR), where:

  • cir cir— Specifies the CIR at which the first token bucket is updated as a value in bits per second. Valid values are 8000 to 200000000.
  • bc conform-burst— (Optional) Specifies the conform burst (bc) size in bytes used by the first token bucket for policing. Valid values are 1000 to 51200000.
  • pir pir— Specifies the PIR at which the second token bucket is updated as a value in bits per second. Valid values are 8000 to 200000000.
  • be peak-burst— (Optional) Specifies the peak burst (be) size in bytes used by the second token bucket for policing. The size varies according to the interface and platform in use.
  • action— (Optional) Specifies the policing command (as shown in Table 5-18 ) for the action to be applied to the corresponding conforming, exceeding, or violating traffic.

Step 6

Router(config-pmap-c)# police flow { bits-per-second [ normal-burst-bytes ] [ maximum-burst-bytes ] [ pir peak-rate-bps ]} | [ conform-action action ] [ exceed-action action ] [ violate-action action ]

Configures a microflow policer, where:

  • bits-per-second— Specifies the CIR in bits per second. Valid values are from 32000 to 4000000000 bits per second.
  • normal-burst-bytes— (Optional) Specifies the CIR token bucket size. Valid values are from 1000 to 512000000 bytes.
  • maximum-burst-bytes— (Optional) Specifies the PIR token-bucket size. Valid values are from 1000 to 32000000 bytes.
  • pir peak-rate-bps— (Optional) Specifies the PIR in bits per second. Valid values are from 32000 to 4000000000 bits per second.
  • action— Specifies the policing command (as shown in Table 5-18 ) for the action to be applied to the corresponding conforming, exceeding, or violating traffic.

Step 7

Router(config-pmap-c)# police flow mask { dest-only | full-flow | src-only } { bits-per-second [ normal-burst-bytes ] [ maximum-burst-bytes ]} [ conform-action action ] [ exceed-action action ]

Configures a flow mask to be used for policing, where:

  • dest-only —Specifies the destination-only flow mask.
  • full-flow —Specifies the full-flow mask.
  • src-only —Specifies the source-only flow mask.
  • bits-per-second— Specifies the CIR in bits per second. Valid values are from 32000 to 4000000000 bits per second.
  • normal-burst-bytes— (Optional) Specifies the CIR token bucket size. Valid values are from 1000 to 512000000 bytes.
  • maximum-burst-bytes— (Optional) Specifies the PIR token bucket size. Valid values are from 1000 to 32000000 bytes.
  • action— Specifies the policing command (as shown in Table 5-18 ) for the action to be applied to the corresponding conforming or exceeding traffic.

Step 8

Router(config-pmap-c)# police aggregate name

Specifies a previously defined aggregate policer name and configures the policy-map class to use the specified name of the aggregate policer.

Table 5-18 provides information about which policing actions are supported for SIPs on the Cisco 7600 series router.


NoteFor restrictions on use of certain marking features with different types of policing actions (conform, exceed, or violate actions), be sure to see the“QoS Traffic Policing Policy Configuration Guidelines” section.


 

Table 5-18 QoS Policing Action Compatibility by SIP and SPA Combination

Policing Action (set command)
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

Drop the packet

( drop command)

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs—Input interface only.

Set the ATM CLP bit to 1 and transmit

( set-clp-transmit command)

Supported only for ATM SPAs.

Supported only for CeoP and ATM SPAs.

Not supported.

Set the inner CoS value and transmit

( set-cos-inner-transmit command)

Supported in Cisco IOS Release 12.2(33)SRA with bridging features.

Supported in Cisco IOS Release 12.2(33)SRA with bridging features.

Not supported.

Set the Frame Relay DE bit to 1 and transmit

( set-frde-transmit command)

Supported for all SPAs.

Supported for all SPAs.

Not supported.

Set the IP precedence and transmit

( set-prec-transmit command)

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs —Input interface only.

Set the IP DSCP and transmit

( set-dscp-transmit command)

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs—Input interface only.

Set the MPLS EXP bit (0–7) on imposition and transmit

( set-mpls-experimental-imposition-transmit command

Supported for all SPAs.

Supported for all SPAs.

Supported for all SPAs.

Set the MPLS EXP bit in the topmost label and transmit

( set-mpls-experimental-topmost-transmit command)

Supported for all SPAs.

Supported for all SPAs.

Refer to QoS Traffic Class Configuration Guidelines

Supported for all SPAs.

Transmit all packets without alteration

( transmit command)

Supported for all SPAs.

Supported for all SPAs

Supported for all SPAs.

Attaching a QoS Traffic Policy to an Interface

Before a traffic policy can be enabled for a class of traffic, it must be configured on an interface. A traffic policy also can be attached to an ATM permanent virtual circuit (PVC) subinterface, Frame Relay data-link connection identifier (DLCI), and Ethernet subinterfaces.

Traffic policies can be applied for traffic coming into an interface (input), and for traffic leaving that interface (output).

Effective from Cisco IOS release 15.2(4)S3, policy-map installations is not allowed in the same direction (input or output) for the following combinations:

  • Installing simultaneously with QoS policies on both main interface and its PVC
  • Installing simultaneously with QoS policies on both sub-interface and its PVC
  • Installing simultaneously with QoS policies on both Frame Relay main interface and its DLCI
  • Installing simultaneously with QoS policies on both Frame Relay sub-interface and its DLCI
  • Installing simultaneously with QoS policies on both Ethernet main interface and its EVC
  • Installing simultaneously with QoS policies on both Ethernet sub-interface and its EVC

Configuring any of the above on a SIP 200 interface, rejects the policy applied and also results in a SIP 200 crash. As mentioned above, the interface could be ATM, Frame-relay or Ethernet.

Attaching a QoS Traffic Policy for an Input Interface

When you attach a traffic policy to an input interface, the policy is applied to traffic coming into that interface. To attach a traffic policy for an input interface, use the following command beginning in interface configuration mode:

 

Command
Purpose

Router(config-if)# service-policy input policy-map-name

Attaches a traffic policy to the input direction of an interface, where:

  • policy-map-name —Specifies the name of the traffic policy to configure.

Attaching a QoS Traffic Policy to an Output Interface

When you attach a traffic policy to an output interface, the policy is applied to traffic leaving that interface. To attach a traffic policy to an output interface, use the following command beginning in interface configuration mode:

 

Command
Purpose

Router(config-if)# service-policy output policy-map-name

Attaches a traffic policy to the output direction of an interface, where:

  • policy-map-name —Specifies the name of the traffic policy to configure.

Configuring Network-Based Application Recognition and Distributed Network-Based Application Recognition


NoteNetwork-Based Application Recognition (NBAR) and Distributed Network-Based Application Recognition (dNBAR) are supported on the Cisco 7600 SIP-200 only. NBAR feature is not supported in Release 15.0(1)S and later Releases.


The purpose of IP quality of service (QoS) is to provide appropriate network resources (bandwidth, delay, jitter, and packet loss) to applications. QoS maximizes the return on investments on network infrastructure by ensuring that mission-critical applications get the required performance and noncritical applications do not hamper the performance of critical applications.

IP QoS can be deployed by defining classes or categories of applications. These classes are defined by using various classification techniques available in Cisco IOS software. After these classes are defined and attached to an interface, the desired QoS features, such as marking, congestion management, congestion avoidance, link efficiency mechanisms, or policing and shaping can then be applied to the classified traffic to provide the appropriate network resources amongst the defined classes.

Classification, therefore, is an important first step in configuring QoS in a network infrastructure.

NBAR is a classification engine that recognizes a wide variety of applications, including web-based and other difficult-to-classify protocols that utilize dynamic TCP/UDP port assignments. When an application is recognized and classified by NBAR, a network can invoke services for that specific application. NBAR ensures that network bandwidth is used efficiently by classifying packets and then applying QoS to the classified traffic. 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)

NoteThe NBAR feature is used for classifying traffic by protocol. The other class-based QoS features determine how the classified traffic is forwarded and are documented separately from NBAR.

Furthermore, NBAR is not the only method of classifying network traffic so that QoS features can be applied to classified traffic.

For information on the class-based features that can be used to forward NBAR-classified traffic, see the individual feature modules for the particular class-based feature as well as the Cisco IOS Quality of Service Solutions Configuration Guide.

Many of the non-NBAR classification options for QoS are documented in the “Modular Quality of Service Command-Line Interface” section of the Cisco IOS Quality of Service Solutions Configuration Guide. These commands are configured using the match command in class map configuration mode.


NBAR introduces several new classification features that identify applications and protocols from Layer 4 through Layer 7:

  • Statically assigned TCP and UDP port numbers
  • Protocols that are non-UDP and non-TCP
  • Dynamically assigned TCP and UDP port numbers. Classification of such applications requires stateful inspection; that is, the ability to discover the data connections to be classified by parsing the connections where the port assignments are made.
  • Sub-port classification or classification based on deep packet inspection; that is, classification by looking deeper into the packet.

NBAR can classify static port protocols. Although access control lists (ACLs) can also be used for this purpose, NBAR is easier to configure and can provide classification statistics that are not available when using ACLs.

NBAR includes a Protocol Discovery feature that provides an easy way to discover application protocols that are transversing an interface. The Protocol Discovery feature discovers any protocol traffic supported by NBAR. Protocol Discovery maintains the following per-protocol statistics for enabled interfaces: total number of input and output packets and bytes, and input and output bit rates. The Protocol Discovery feature captures key statistics associated with each protocol in a network that can be used to define traffic classes and QoS policies for each traffic class.

For specific information about configuring NBAR and dNBAR, refer to the Network-Based Application Recognition and Distributed Network-Based Application Recognition feature documentation located at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/dtnbarad.htm

Configuring Hierarchical QoS on a SIP

Table 5-19 provides information about where the hierarchical QoS features for SPA interfaces are supported.

 

Table 5-19 Hierarchical QoS Feature Compatibility by SIP and SPA Combination

Feature
Cisco 7600 SIP-200
Cisco 7600 SIP-400
Cisco 7600 SIP-600

Hierarchical QoS for EoMPLS VCs

Supported for all SPAs in Cisco IOS Release 12.2(18)SXE and later, and in Cisco IOS Release 12.2(33)SRA.

Supported for all SPAs beginning in Cisco IOS Release 12.2(33)SRA.

Supported for all SPAs in Cisco IOS Release 12.2(18)SXF and later, and in Cisco IOS Release 12.2(33)SRA.

Hierarchical QoS—Tiered policy maps with parent policy using class-default only on the main interface.

Not applicable.

Supported for all SPAs in Cisco IOS Release 12.2(18)SXF and later.

Supported in Cisco IOS Release 12.2(18)SXF and later, and in Cisco IOS Release 12.2(33)SRA using match vlan command in parent policy.

Hierarchical QoS—Tiered policy maps with parent policy in user-defined or class-default classes on the main interface.

Supported for all SPAs in Cisco IOS Release 12.2(18)SXF and later, and in Cisco IOS Release 12.2(33)SRA.

Supported for all SPAs in Cisco IOS Release 12.2(33)SRA.

Not supported.

Configuring Hierarchical QoS with Tiered Policy Maps

Hierarchical QoS with tiered policy maps is a configuration where the actions associated with a class contain a queuing action (such as shaping) and a nested service policy, which in itself is a policy map with classes and actions. This hierarchy of the QoS policy map is then translated into a corresponding hierarchy of queues.

Hierarchical QoS with Tiered Policy Maps Configuration Guidelines

When configuring hierarchical QoS with tiered policy maps on a SIP, consider the following guidelines:

  • For information about where hierarchical QoS with tiered policy maps is supported, see Table 5-19.
  • You can configure up to three levels of hierarchy within the policy maps.
  • The parent policy map has the following restrictions on a main interface:

In Cisco IOS Release 12.2(18)SXF and later—Supports the shape queueing action in the default class (class-default) only.

In Cisco IOS Release 12.2(33)SRA—Supports VLAN or ACL matching, and shape or bandwidth queueing actions in any class, user-defined and class-default.

  • When configuring hierarchical QoS for software-based EoMPLS on the Cisco 7600 SIP-600, if you configure match input vlan in the parent policy, then you can only configure match qos-group in the child policy.
  • In hierarchical QoS, you cannot configure just a set command in the parent policy. The set command works only if you configure other commands in the policy.
  • The child policy map supports shape, bandwidth, LLQ, queue limit, and WRED QoS features.
  • With hierarchical QoS on a subinterface, the parent policy map supports hierarchical QoS using the shape average command as a queueing action in the default class (class-default) only.
  • If you configure service policies at the main interface, subinterface, and VC levels, then the policy applied at the VC level takes precedence over a policy at the interface.
  • In a Frame Relay configuration, if you need to define service policies at the interface, subinterface, and PVC at the same time, then you can use a map class.
  • For a POS subinterface with a Frame Relay PVC, a service policy can be applied either at the subinterface or at the PVC, but not both.
  • Use a hierarchical policy if you want to achieve minimum bandwidth guarantees using CBWFQ with a map class. First, configure a parent policy to shape to the total bandwidth required (use the class-default in Cisco IOS Release 12.2(18)SXF, or a user-defined class beginning in Cisco IOS Release 12.2(33)SRA). Then, define a child policy using CBWFQ for the minimum bandwidth percentages.
  • You can configure hierarchical QoS up to the following limits, according to the current Cisco IOS software limits:

Up to 1024 class maps

Up to 1024 policy maps

Up to 256 classes within a policy map

Up to 8 match statements per class

  • If a hierarchical policy-map is applied on the SIP-400 interface , the child policy will only receive the packets which are not dropped by its parent. In other words, packets which are dropped in parent policy-map in a particular class because of some qos action are not visible to child policy-maps attached to that class and thus will not be classified.

An example is illustrated:

Class-map: voip (match-any)
16894 packets, 4375196 bytes
30 second offered rate 116000 bps, drop rate 108000 bps
Match: any
Priority: 32 kbps, burst bytes 1500, b/w exceed drops: 889
police:
cir 100000 bps, bc 3125 bytes
conformed 968 packets, 250362 bytes; actions:

Only these are passed and the rest are dropped

transmit
exceeded 15926 packets, 4124834 bytes; actions:
drop
conformed 100000 bps, exceed 1649000 bps
 
Service-policy : out
Counters last updated 00:00:01 ago
 
Class-map: prec0 (match-any)
966 packets, 250194 bytes

Only those packets which are not dropped in parent pmap are seen by this child policy-map.

30 second offered rate 8000 bps, drop rate 7000 bps
Match: ip precedence 0
QoS Set
precedence 2
Packets marked 966
police:
cir 8000 bps, bc 1500 bytes
conformed 77 packets, 19943 bytes; actions:
transmit
exceeded 889 packets, 230251 bytes; actions:
drop
conformed 8000 bps, exceed 91000 bps

 

Configuring Hierarchical QoS for EoMPLS VCs

The Hierarchical Quality of Service (HQoS) for EoMPLS VCs feature extends support for hierarchical, parent and child relationships in QoS policy maps. This feature also provides EoMPLS per-VC QoS for point-to-point VCs.

The new feature adds the ability to match the virtual LAN (VLAN) IDs that were present on a packet when the packet was originally received by the router. It also supports the ability to match on a QoS group that is set to the same value of the IP precedence or 802.1P class of service (CoS) bits that are received on the incoming interface. This allows service providers to classify traffic easily for all or part of a particular EoMPLS network, as well as to preserve the customer’s original differentiated services (DiffServ) QoS values.

In EoMPLS applications, the parent policy map typically specifies the maximum or the minimum bandwidth for a group of specific VCs in an EoMPLS network. Then child policy maps in the policy can implement a different bandwidth or perform other QoS operations (such as traffic shaping) on a subset of the selected VCs.

This feature enables service providers to provide more granular QoS services to their customers. It also gives service providers the ability to preserve customer IP precedence or CoS values in the network.


NoteFor information about where hierarchical QoS for EoMPLS VCs is supported, seeTable 5-19.


For more information about configuring hierarchical QoS for EoMPLS VCs, refer to the Optical Services Module Configuration Note located at the following URL:

http://www.cisco.com/en/US/docs/routers/7600/install_config/12.2SR_OSM_config/OSM.pdf

Configuring PFC QoS on a Cisco 7600 SIP-600

The Cisco 7600 SIP-600 supports most of the same QoS features as those supported by the Policy Feature Card on the Cisco 7600 series router.

This section describes those QoS features that have SIP-specific configuration guidelines. After you review the SIP-specific guidelines described in this document, then refer to the Cisco 7600 Series Cisco IOS Software Configuration Guide, 12.2SR located at the following URL:

http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/swcg.html

PFC QoS on a Cisco 7600 SIP-600 Configuration Guidelines

  • Output policing is not supported.

Configuring NAT

This section describes guidelines for configuring Network Address Translation (NAT). Developed by Cisco, NAT allows a single device, such as a router, to act as agent between the Internet public network and a local private network.

For details on NAT refer to Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide, 2.2 located at the following URL:

http://www.cisco.com/en/US/docs/security/fwsm/fwsm22/configuration/guide/nat.html

For NAT configuration commands refer to the Cisco IOS IP Addressing Services Command Reference located at the following URL:

http://www.cisco.com/en/US/docs/ios/ipaddr/command/reference/iad_nat.html


Restrictions

  • As a general restriction, while configuring NAT make sure nat pool size is limited to 15 bits.
  • If you configure the nat pool size to more than 15 bits the following error message is displayed on the system:
Error Message pool size should be maximum 15 bits long.
  • NAT is not supported on the WS-SVC-SAMI-BB-K9 module.

Configuring Lawful Intercept on a Cisco 7600 SIP-400

This section describes configuring Lawful Intercept on a Cisco 7600 SIP-400. For initial configuration of the Lawful Intercept feature, see the Cisco 7600 Lawful Intercept Configuration Guide at the following URL:

http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/lawful_intercept/76licfg.html

SUMMARY STEPS

    • snmp-server view viewA ciscoTap2MIB included
      OR
      snmp-server view viewA ciscoIpTapMIB included
    • snmp-server group groupA v3 auth read viewA write viewA notify viewA
    • snmp-server user user1 groupA v3 auth md5 cisco

DETAILED STEPS

To configure Lawful Intercept on a Cisco 7600 SIP-400, use the following commands:

 

Command
Purpose

Router(config)# snmp-server view viewA ciscoTap2MIB included

Router(config)# snmp-server view viewA ciscoIpTapMIB included

Creates a view having access to the MIBS.

Router(config)# snmp-server group groupA v3 auth read viewA write viewA notify viewA

Creates a group having access to this view.

Router(config)# snmp-server user user1 groupA v3 auth md5 cisco

Creates a user who is a member of groupA.

Configuring Security ACLs on an Access Interface on a Cisco 7600 SIP-400

This section describes configuration of the SIP-specific ACL features on access interfaces. Before referring to any other ACL documentation for the platform or in the Cisco IOS software, use this section to determine SIP-specific ACL feature support and configuration guidelines.

An Access Control List (ACL) is a collection of ordered permit and deny statements, referred to as Access Control Entries (ACEs), which determine whether a particular packet will be forwarded or dropped. An ACL offers application layer awareness, providing operational staff with some flexibility in the level of isolation of a host. For instance, an ACL may be applied to enforce complete host isolation, denying all traffic to and from that particular host or, alternately, to just filter certain traffic flows, while permitting all others.

For additional details about ACL concepts and features in Cisco IOS Release 12.2, refer to the Cisco IOS Security Configuration Guide, Release 12.2, at the following URL:

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

This section includes the following topics:

Security ACL Configuration Guidelines

  • Up to 100 unique ACLs are recommended per chassis, with a maximum of 24 ACEs per ACL for Security ACL.
  • Up to one input ACL and one output ACL are recommended for all 8K subinterfaces on the SIP.
  • Source and Destination IPv4 Address, Port Number, ToS/DSCP, Protocol type, and TCP flags can be specified in the ACEs. As of Cisco IOS Release 12.2(33)SRB, IPV6 is not supported.
  • Template Security ACL is not supported as of Cisco IOS Release 12.2(33)SRB.
  • Security ACLs are only supported on a Route Switch Processor 720 (RSP720) with a Cisco 7600 SIP-400.
  • Standard, extended, and named ACLs are supported; other ACL types such as reflexive and time-based ACLs are not supported.

Configuring Security ACL

SUMMARY STEPS


Step 1 access-list access list number permit ip host ip address any

Step 2 interface gigabitethernet slot / subslot / port access

Step 3 ip address address

Step 4 encapsulation dot1q vlan-id

Step 5 ip access-group access-list-number in

Step 6 ip access-group access-list-number out

DETAILED STEPS

 

Command or Action
Purpose

Step 1

Router(config)# access-list access list

number permit ip host ip address any

Configures an access list.

Step 2

Router(config-int)# interface gigabitethernet slot / subslot / port access

Selects the gigabitethernet interface.

Step 3

Router(config-int)# ip address address

Specifies the IP address.

Step 4

Router(config-int)# encapsulation dot1q vlan-id

Enables traffic encapsulation.

  • vlan-id— Virtual LAN identifier; valid values are from 1 to 4094.

Step 5

Router(config-int)# ip access-group access-list-number in

Sets filtering method.

  • access-list-number— Number of an access list. This is a decimal number from 1 to 199 or 1300 to 2699.
  • in Filters on inbound packets.

Step 6

Router(config-int)# ip access-group access-list-number out

Sets filtering method.

  • access-list-number— Number of an access list. This is a decimal number from 1 to 199 or 1300 to 2699.
  • out— Filters on outbound packets.

Verifying ACL Configuration

Use the following command to verify ACL configuration:

 

Command or Action
Purpose

Router# show access-list [ access-list-number | name ]

Displays access list configuration.

  • access-list-number— (Optional) Access list number to display. The range is 0 to 1199. The system displays all access lists by default.
  • name —(Optional) Name of the IP access list to display.

Configuring CoPP on the Cisco 7600 SIP-400

This section describes the configuration of Control Plane Policing (CoPP) on the Cisco 7600 SIP-400.

Because the majority of control plane processing is done on the CPU, a malicious user can attack a router by simply pumping control plane traffic to the router. On an unprotected router, this results in the CPU utilization nearing 100%, resource exhaustion, and the command line console being locked, intensifying the problem because the user is not able to apply any rectifying action on the router.

Using CoPP protects the control plane against these denial-of-service (DoS) attacks, ensuring routing stability, reachability, and packet delivery by providing filtering and rate-limiting capabilities for control plane packets.

For additional information regarding DoS and CoPP, refer to the Cisco 7600 Series Router Cisco IOS Software Configuration Guide .

This section contains the following topics:

Configuring Per-Subscriber/Per-Protocol CoPP on Access Interfaces on a Cisco 7600 SIP-400

This section describes the configuration of Per-Subscriber/Per-Protocol CoPP on a Cisco 7600 SIP-400.

Per-Subscriber/Per-Protocol CoPP Configuration Guidelines

  • The Cisco 7600 CoPP feature is supported with a Route Switch Processor 720 (RSP720) and Cisco 7600 SIP-400 combination only.
  • When enabling the RP-based aggregate CoPP functionality, the required class maps should be configured for each of the protocol-matching criteria. The CoPP policy maps should be created for all the protocols that need to be policed.
  • Once the router processor decides to install a rate-limiter on an interface, there will be a delay for actually installing the rate-limiter on the Cisco 7600 SIP-400. During this interval, it is possible that the aggregate rate-limiter would start dropping good user packets, if the per-interface rates are not chosen carefully. For example, consider that there are 10 interfaces and 100 pps is used as the aggregate rate and 15 pps as the per-interface rate. If there are seven attacks on the router at a time, the aggregate limit would be exceeded and user traffic would be affected.
  • As of Cisco IOS Release 12.2(33)SRB, the CoPP Per-subscriber/Per-Protocol feature is only supported for DHCP, ARP, and ICMP protocols. DHCP and ARP policing are performed on the SPA, while ICMP policing is performed at the router processor level.

SUMMARY STEPS

    • class-map arp-peruser
    • match protocol arp
    • match subscriber access
    • class-map dhcp-peruser
    • match protocol dhcp
    • match subscriber access
    • policy-map copp-peruser
    • class arp-peruser
    • police rate units pps burst burst-in-packets packets
    • control-plane user-type access
    • service-policy input copp-peruser
    • platform copp observation-period time
    • platform copp interface arp off

DETAILED STEPS

To configure Per-Subscriber/Per-Protocol CoPP support, use the following commands:

 

Command or Action
Purpose

Router(config)# class-map arp-peruser

Creates a class map for ARP.

Router(config-cmap)# match protocol arp

Matches ARP traffic.

Router(config-cmap)# match subscriber access

Defines the class map for access interfaces.

Router(config)# class-map dhcp-peruser

Creates a class map for DHCP.

Router(config-cmap)# match protocol dhcp

Configures the match criterion for a DHCP class map.

Router(config-cmap) match subscriber access

Defines the class map for access interfaces.

Router(config)# policy-map copp-peruser

Specifies CoPP as the policy map.

Router(config-pmap)# class arp-peruser

Creates an ARP peruser class.

Router(config-pmap-c)# police rate units pps burst burst-in-packets packets

Specifies the burst rate.

  • units —Rate at which traffic is policed in packets per second. Valid values are 1 to 2000000 pps.
  • burst-in-packets —(Optional) Specifies the burst rate that is used for policing traffic. Valid values are 1 to 512000 packets.

Router(config-pmap-c)# class dhcp-peruser

Creates a DHCP peruser class.

Router(config-pmap-c)# police rate units pps burst burst-in-packets packets

Specifies the burst rate.

  • units —Rate at which traffic is policed in packets per second. Valid values are 1 to 2000000 pps.
  • burst-in-packets —(Optional) Specifies the burst rate that is used for policing traffic. Valid values are 1 to 512000 packets.

Router(config)# control-plane user-type access

Applies the policy on control-plane-user interface.

Router(config-cp-user)# service-policy input copp-peruser

Configures the per-user policy map.

Router(config)# platform copp observation-period time

Configures the observation window.

  • time —Amount of time in minutes.

Router# platform copp interface arp off

Clears a per-subinterface rate-limiter for ARP on an interface.

  • interface —Defines interface.

Verifying Per-Subscriber/Per-Protocol CoPP

To verify Per-Subscriber/Per-Protocol CoPP configuration, use the following commands:

 

Command or Action
Purpose

Router# show platform copp rate-limit [ arp | dhcp | all ]

Displays configuration settings.

  • arp— Displays ARP information.
  • dhcp —Displays DHCP information.
  • all —Displays ARP and DHCP information.

Router# show policy-map policy-map-name

Verifies that packets match the desired class.

  • policy-map-name— (Optional) Name of the policy map.

Configuring Per-Subinterface CoPP on Access Interfaces on a Cisco 7600 SIP-400

This section describes the configuration of Per-Subinterface CoPP on a Cisco 7600 SIP-400.

Per-Subinterface CoPP Configuration Guidelines

This section describes guidelines to consider when configuring Per-Subinterface CoPP.

  • Per-Subinterface CoPP is supported on Cisco 7600 series routers with Supervisor 720, SIP-400, and Ethernet SPAs.
  • The following packet types can be rate-limited on the SIP-400:

DHCP packets

ARP packets

ATM OAM packets

Ethernet OAM packets

PPPoE discovery packets


Note DHCP and ARP packets are supported in Cisco IOS Release 12.2(33)SRB and later. ATM OAM, Ethernet OAM, and PPPoE discovery packets are supported in Cisco IOS Release 12.2(33)SRC and later.


  • If there is a normal QoS policy installed on an interface, the SIP-400 first applies the QoS policy, then the Security ACL, then the CoPP rate-limiter on a packet.
  • During a switchover, all dynamic rate-limiters on the router are turned off.
  • During online insertion and removal (OIR) of a line card, the rate-limiters on the interfaces are reset.

Configuring Per-Subinterface CoPP

SUMMARY STEPS

    • class-map class-map-name
    • match protocol protocol-name [ arp | dhcp | atm-oam | ethernet-oam | pppoe-discovery]
    • match subscriber access
    • policy-map policy-map-name
    • class class-map-name
    • police rate units [ pps burst burst-in-packets packets | bps burst burst-in-bytes bytes ]
    • control-plane user-type access
    • service-policy input policy-map-name
    • platform copp observation-period time
    • platform copp interface protocol-name off

DETAILED STEPS

To configure Per-Subinterface CoPP support, use the following commands:

 

Command or Action
Purpose

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

Creates a class map for the packet protocol.

Router(config-cmap)# match protocol protocol-name [ arp | dhcp | atm-oam | ethernet-oam | pppoe-discovery]

Matches packet protocol traffic.

Router(config-cmap)# match subscriber access

Defines the class map for access interfaces.

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

Specifies CoPP as the policy map.

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

Creates a class map for the packet protocol.

Router(config-pmap-c)# police rate units [ pps burst burst-in-packets packets | bps burst burst-in-bytes bytes ]

Specifies the burst rate.

  • units —Rate at which traffic is policed in packets per second. Valid values are 1 to 2000000.
  • burst-in-packets —(Optional) Specifies the burst rate (in packets per second) that is used for policing traffic. Valid values are 1 to 512000 packets.
  • burst-in-bytes—(Optional) Specifies the burst rate (in bytes per second) that is used for policing traffic. Valid values are 100 to 1000 bytes.

Router(config)# control-plane user-type access

Applies the policy on the control-plane user interface.

Router(config-cp-user)# service-policy input policy-map-name

Configures the policy map.

Router(config)# platform copp observation-period time

Configures the observation window.

  • time —Amount of time in minutes.

Router# platform copp interface protocol-name off

Clears a per-subinterface limiter for the packet protocol on an interface.

  • interface —Defines the interface.
  • protocol-name —Defines the packet protocol.

Verifying Per-Subinterface CoPP

To verify Per-Subinterface CoPP configuration, use the following commands:

 

Command or Action
Purpose

Router# show platform copp rate-limit protocol-name [ arp | dhcp | atm-oam | ethernet-oam | pppoe-discovery | all]

Displays configuration settings for the selected packet protocol or all protocols.

Router# show platform np copp [ ifnum ] [ detail ]

Displays debug information for a given session or for all sessions.

  • ifnum —Identifies a specific session ID.
  • detail —Shows full rate-limiting values.

Configuring DBUS COS Queuing on SIP-400

Packets coming from the Hyperion ASIC to the SIP-400 switch are buffered in two queues - High Priority (HP) and Low Priority (LP). Packets with the Bridge Protocol Data Unit (BPDU) bit or certain Class-of-Service (CoS) values set, are sent as high-priority. When the BPDU bit is not set, egress packets on the SIP-400 switch are placed in an internal low or high priority queue.

This feature provides a CLI to allow the user to specify the DBUS CoS values in the SIP-400 switch's high priority queue.


NoteThe CoS values can only be set in the internally generated DBUS header and not in headers that exist prior to the packet entering the Cisco 7600 router or those on packets leaving the Cisco 7600 router.


The configuration is available per slot and not in the global configuration mode. This is so that any line card can be configured to use hardware configuration values stored for that slot independent of any other line card in the chassis.

If no values are specified using the command, then SIP-400 cards use the default DBUS CoS values of 5, 6, and 7. The CoS values input from the command are stored in the running configuration. These configured values are set whenever there is a line card Online Insertion or Removal (OIR). If the SIP-400 card is physically removed from the chassis, the configured CoS values are removed from the running configuration. If the SIP-400 is reinserted in the chassis, the default CoS values are used until the configuration is modified.

This feature has a minimal impact on memory and bandwidth.

Configuration Guidelines and Restrictions

Keep the following guidelines in mind while configuring this feature:

  • DBUS COS Queuing is supported only on the SIP-400.
  • The DBUS COS Queuing command allow the end user to only control the CoS value queuing behavior. The command does not allow the user to specify queuing behavior for the BPDU bit.
  • For the SIP-400, a warning message is displayed if the values 6 and 7 do not map to the priority queue.

Configuration Steps

Use the commands described in the following sections to configure the DBUS COS Queuing on SIP-400:

SUMMARY STEPS


Step 1 Router# hw-module slot slot queue priority switch-fpga output cos values |none

Step 2 Router# no hw-module slot slot queue priority switch-fpga output

DETAILED STEPS

Command or Action
Purpose

Router# hw-module slot slot queue priority switch-fpga output cos values |none

Example:

Router# hw-module slot 5 queue priority switch-fpga output none

S pecifies the CoS values that are placed in the SIP-400 switch high priority queue.

slot is the slot being configured in the chassis

cos values are in the range of 0-7.

If the none keyword is specified, all the CoS values go to the SIP-400 switch's low priority queue.

Note If CoS values 6 and 7 are not set to the SIP-400 switch's high priority queue by the CLI, then the terminal displays a SIP-400 specific warning message, since not prioritizing the valuescan severely affect performance.

The each individual cos value should be formatted with a space in between like 4 5 6 7.

You can configure non-consecutive values example 3 5 6 7 as long as 6 and 7 are included in the list.

This command replaces any values that were previously set.

Router# no hw-module slot slot queue priority switch-fpga output

Example:

Router# no hw-module slot 5 queue priority switch-fpga output

Sets the CoS values back to the defaults

Sample configuration

The following is an example of the feature configuration:

Router# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)# ! Map only CoS values 4, 5, 6, and 7 to the high priority queue

Router(config)# hw-module slot 5 queue priority switch-fpga output 4 5 6 7

Router(config)# ! Map only CoS values 6 and 7 to the high priority queue

Router(config)# ! Note that this un-maps 4 and 5 from the high priority queue

Router(config)# hw-module slot 5 queue priority switch-fpga output 6 7

Router(config)# do show running-config | include qos-priority

Router(config)# hw-module slot 5 queue priority switch-fpga output 6 7

Router(config)# ! Remove all CoS values from the high priority queue

Router(config)# hw-module slot 5 queue priority switch-fpga output none

WARNING: CoS values 6 and 7 are typically considered high priority.

Setting these values to low priority may cause service disturbances during traffic congestion.

Router(config)# do show running-config | include switch-fpga

Router(config)# hw-module slot 5 queue priority switch-fpga output none

HELP Messages

You can access command line help to view command options and allowed arguments, while configuring the feature. Some examples are illustrated below:


Router(config)#hw-module slot 5 ?

queue Linecard internal queueing configuration

Router(config)#hw-module slot 5 queue ?

priority Specify priority values

Router(config)#hw-module slot 5 queue priority ?

switch-fpga Switch FPGA internal queueing configuration

Router(config)#hw-module slot 5 queue priority switch-fpga ?

output Output policy

Router(config)#hw-module slot 5 queue priority switch-fpga output ?

<0-7> Up to 8 class of service values separated by spaces

none No priority values

Verifying the DBUS COS Queuing Configuration

Use the following show commands to verify the DBUS COS Queuing configuration:

Show Command
Description

SIP-400#show platform hardware bonham counters

Displays the aggregate counters for both low and high priority packets dropped by the SIP-400 switch due to egress oversubscription.

Note The SIP-400 switch does not maintain per-interface counters for these dropped packets but aggregates them.

SIP-400# show platform hardware bonham register | inc Priority

Shows the setting in hardware

The first bit is CoS 0 and the ninth bit is BPDU.

SIP-400# show platform hardware bonham counters | inc PKT BUF

Shows the total packet count through high-priority and low-priority queues

Verification Examples

SIP-400-5#show platform hardware bonham counters

Bonham Packet Counters:
AEFC A S Packets (offset 0x00A2) 0
AEFC B S Packets (offset 0x00A6) 0
AEFC A BG Packets (offset 0x00AA) 0
AEFC B BG Packets (offset 0x00AE) 0
SPI Tx Packets (offset 0x018C) 305473085
SPI Rx Packets (offset 0x0212) 851791536
DDR Tx Hi Packets (offset 0x028C) 1
DDR Tx Low Packets (offset 0x0290) 851785180
DDR Rx Packets (offset 0x030A) 306352642
CP FIFO Tx Packets (offset 0x0388) 6446
CP FIFO Rx Packets (offset 0x0408) 6455
INP to ENP Packets (offset 0x0488) 0
PKT BUF HP Packets (offset 0x050C) 30000000
PKT BUF LP Packets (offset 0x0510) 275466630
AEFC A Good Notify (offset 0x00CA) 0
AEFC A Bad Notify (offset 0x00CE) 1
AEFC B Good Notify (offset 0x00D2) 0
AEFC B Bad Notify (offset 0x00D6) 1
AEFC A Sent Msg (offset 0x00DA) 0
AEFC A Drop Msg (offset 0x00DE) 0
AEFC B Sent Msg (offset 0x00E2) 0
AEFC B Drop Msg (offset 0x00E6) 0
Error Counters:
SPI Rx Addr Errors (offset 0x0204) 0
DDR Rx Hdr CRC Err (offset 0x030E) 0
DDR Rx Pkt CRC Err (offset 0x0312) 0
DDR Rx Seq Errors (offset 0x0316) 0
DDR Rx Len Errors (offset 0x031A) 0
DDR Tx HP Errors (offset 0x0294) 0
DDR Tx LP Errors (offset 0x0298) 0
CP FIFO Tx Errors (offset 0x038C) 0
CP FIFO Rx Errors (offset 0x040C) 0
CP FIFO Rx Seq Err (offset 0x0410) 0
INP to ENP Errors (offset 0x048C) 0
Pkt buf HP pkt drops (offset 0x0534) 0
Pkt buf LP pkt drops (offset 0x0538) 886012
Pkt buf LLQ pkt drops(offset 0x0546) 0

 

Packets which are classified as high priority in the egress path are reflected in the 'PKT BUF HP Packets' counter. Low priority packets are reflected in the 'PKT BUF LP Packets" counter.

High priority packets that have been dropped by the SIP-400 switch because of backpressure from the egress network processor, are reflected in the 'Pkt buf HP pkt drops' counter. Low priority drops are reflected in the 'Pkt buf LP pkt drops' counter.

Configuring IPv6 Hop-by-Hop Header Security on SIP-200 or SIP-400

IPv6 Hop-by-Hop (HBH) extension header is part of the original specification of the IPv6 protocol (RFC 2460). An IPv6 packet Hop-by-Hop extension header is identified by the header type 0, and when present, this extension header must always be the first extension header (EH) to follow the main header. Because a node must process any received packet that has an HBH extension header, forwarding packets containing the HBH header can represent a security threat. This can happen when a large number of IPv6 packets with Hop-by-Hop (HBH) extension headers are sent, creating a possibility of Denial of Service (DoS) attacks.

The IPv6 - Hop-by-Hop Rate Limiter feature provides protection from Denial of Service (DoS) attacks. This feature allows IPv6 traffic with Hop-by-Hop headers to be rate-limited on the 7600 SIP-400 and SIP-200 line cards.

Cisco IOS Release 12.2(33)SRD1 introduces support for configuring IPv6 Hop-by-Hop policing on SIP-400 and Cisco IOS Release 12.2(33)SRD3 introduces support for this feature on SIP-200.

The Cisco 7600 routers treat IPv6 packets with HBH extension headers as Layer 2 packets. Layer 3 ACLs cannot be applied to these packets; hence a way to rate-limit these on the line card is needed. For Cisco IOS Releases 12.2(33)SRD1 and 12.2(33)SRE, only the first extension header of type Hop-by-Hop is rate-limited by the line card.

The SIP-200 and SIP-400 line cards support this feature on SUP720, SUP32, RSP720-1GE and RSP720-10GE supervisors.

The policer is a Packets-Per-Second (PPS) policer and is per network processor. rate-limits can be configured up to and including 25600 pps. The default police rate is 21.36 k pps, and ROMMON variable is IPv6_policer_rate. Setting the policer rate to zero drops all the IPv6 HBH packets.

Usage Guidelines

The following factors need to be considered while configuring the IPv6 Hop-By-Hop Policing feature:

  • Setting the police rate to 0 drops all the IPv6 HBH packets.
  • After setting the police rate, the setting will remain on the line card even if the line card is moved to another chassis running Cisco IOS Release 12.2(33)SRD3 or later.
  • IPv6 packets with HBH and EH will bypass other QoS configured on the line card.

Supported Supervisor Engines and SPAs

The Cisco 7600 supports IPv6 Hop-By-Hop Policing rate limit on the following :

  • Supervisor engines:

Supervisor Engine 720

Supervisor Engine 32

RSP720-1GE

RSP720-10GE

  • SIP-400 supporting the following SPAs:

SPA-2x1GE-V2

SPA-5x1GE-V2

SPA-2xOC3-POS

SPA-4xOC3-POS

SPA-1xOC12-POS

SPA-1xOC48-POS

SPA-1CHOC3-CE-ATM

SPA-24CHT1-CE-ATM

SPA-2xOC3-ATM

SPA-4xOC3-ATM

SPA-1xOC12-ATM

SPA-1xOC48-ATM

  • SIP-200supporting the following SPAs:

SPA-2xOC3-POS

SPA-4xOC3-POS

SPA-1xOC12-POS

SPA-2xOC3-ATM

SPA-4xOC3-ATM

SPA-1xOC12-ATM

Configuring IPv6 Hop-by-Hop Header Security

To connect to a specific line card for the purpose of executing the test platform police ipv6 set command, test platform police ipv6 get command, or test platform police ipv6 disable use the attach command in privileged EXEC mode.

You can then set the IPv6 internal police rate by using the test platform police ipv6 set command in privileged EXEC mode from the line card console.

SUMMARY STEPS

Use the following summary of commands to configure the IPv6 Hop-by-Hop feature on a SIP-400 or a SIP-200.


Step 1 Router # attach slot

Step 2 SIP-400-slot> enable

Step 3 SIP-400-slot# test platform police ipv6 set rate

Step 4 SIP-400-slot# test platform police ipv6 disable

DETAILED STEPS

Command or Action
Purpose

Router# attach slot

Example:

Router# attach 3

Allows you to log in to the specified interface of the SIP-400 or SIP-200 console.

SIP-400-slot> enable

Example:

SIP-400-3> enable

Enables privileged EXEC mode.

For SIP-400:

SIP-400-3# test platform police ipv6 set rate

Example:

SIP-400-3# test platform police ipv6 set 1022

For SIP-200:

SIP-200-3# test platform police ipv6 set rate

Example:

SIP-200-3# test platform police ipv6 set 300

Sets the IPv6 internal police rate, in packets per second (pps), on the SIP-400 interface.

Sets the IPv6 internal police rate, in packets per second (pps), on the SIP-200 interface.

SIP-400-3# test platform police ipv6 disable

Example:

SIP-400-3# test platform police ipv6 disable

Disables the IPv6 internal policer.

Note On a SIP-400, rate=65535 indicates that the policer is disabled.


NoteTo exit the slot, type Control+C three times from the attach console slot. The ^C^C^C key sequence ends the session. This tip is also displayed as you enter the console slot.


Sample Configuration

To set the policer on the SIP-400 and use the get command to display the configured police rate

PE17_C7606# attach 2
Entering CONSOLE for slot 2
Type "^C^C^C" to end this session
 
 
SIP-400-2> enable
SIP-400-2# test platform police ipv6 set ?
<0-25600> pps, 0 to drop all the IPv6 HBH packets
 
SIP-400-2# test platform police ipv6 set 1000
 
 
SIP-400-2# test platform police ipv6 get
IPv6 with HBH header is policed at 1001.35 pps
 

OR

SIP-400-8# test platform police ipv6 set ?
<0-25600> pps, 0 drop all the IPv6 HBH packets
 
SIP-400-8# test platform police ipv6 set 300
SIP-400-8# test platform police ipv6 get
IPv6 with HBH header is policed at 292.6 pps
 

To disable the IPv6 internal policer on the SIP-400:

SIP-400-8# test platform police ipv6 disable
SIP-400-8# test platform police ipv6 get
IPv6 with HBH header is not policed.

 

To set the policer on the SIP-200 and use the get command to display the configured police rate

SIP-200-2# test platform police ipv6 set 0
Dropping all the IPv6 HBH Policer
SIP-200-2# test platform police ipv6 set 1000
IPv6 HBH packet policer rate = 1000 pps
SIP-200-2# test platform police ipv6 get
IPv6 HBH packet policer rate = 1000 pps, Rate in rommon = 1000 pps

 

To disable the IPv6 internal policer on the SIP-200:

SIP-200-2# test platform police ipv6 disable
SIP-200-2# test platform police ipv6 get
IPv6 with HBH header is not policed.
 
SIP-200-2# show platform software ipv6-policer
IPv6 HBH packet policer rate = 1000 pps
Rate in rommon = 1000 pps
Packets dropped = 297850, Packets punted to RP = 37424
 

Verifying the IPv6 Hop-By-Hop Policing Configuration

To verify the configuration of the IPv6 Hop-by-Hop policing feature, use the following show commands:

Command or Action
Purpose

SIP-400-slot# test platform police ipv6 get

OR

SIP-200-slot# test platform police ipv6 get

Displays the IPv6 internal police rate on the line card.

SIP-400-slot# show platform np rppp rate

Displays information about all the internal policers, where:

  • np refers to the Network Processor.
  • rppp stands for Routing Punt Path Policer.
  • rate signifies the aggregate policer speed at which packets are routed to the RP.

SIP-200-slot#show platform software ipv6-policer

Displays full details of the policer rate limit and rate-limited packets.

Note All the commands listed above can be run on the SIP-400 and SIP-200 line cards.

Verification Examples

To view the policer rate limit:

SIP-400-4# test platform police ipv6 get
 
IPv6 with HBH header is policed at 0.0 pps

 

To view the packets rate-limited :

SIP-400-4# show platform np rppp rate | inc HBH
 
IPv6 HBH packet policer rate = 0.0pps,x = 0,y2 = 0,tokens = 10240, SIP-400-4#

 

SIP-400-3# show platform np rppp rate
 
RPPP NP Client Rate Information:
Default RPPP rate = 1335.14pps,x = 1,y2 = 6,tokens = 10240,
pkts=0
Priority RPPP rate = 1335.14pps,x = 1,y2 = 6,tokens = 10240,
pkts=0
L4R/PBHK configs RPPP rate = 21362.30pps,x = 1,y2 = 2,tokens = 10240,
pkts=0
Broadband FSOL RPPP rate = 10681.15pps,x = 1,y2 = 3,tokens = 10240,
pkts=0
CFM RPPP rate = 1335.14pps,x = 1,y2 = 6,tokens = 4194304,
pkts=0
IPv6 HBH packet policer rate = 21362.30pps,x = 1,y2 = 2,tokens = 10240,
pkts=0

 

SIP-200-1# show platform software ipv6-policer
 
IPv6 HBH packet policer rate = 21000 pps,
Rate in rommon = 21000 pps
Packets dropped = 0 packets, Packets punted to RP = 0.

NoteThe values for setting and getting may not match exactly and are approximated.


Triple Nesting QoS Support on SIP400

Beginning with the Cisco IOS Release 12.2(33)SRE, SIP-400 extends configuration support for three levels of policy on the SIP-400 line card, from the existing support for two levels of queuing. The third level of user-defined QoS policy maps will support non-queuing features.

Triple nesting QoS on SIP-400 allows you to define an MQC policy with parent, child and grand-child (Three nested policies). Queuing classes are supported for parent and child while the third grandchild level supports only non-queuing actions like policing and marking.

The Triple Nesting QoS feature is not expected to have any significant change in memory or CPU utilization on the SIP-400

This policy-map can be applied to following interfaces:

  • PPP Main Interface
  • Sub Interfaces
  • EVC (either on the main interface or on the subinterface configured with dot1q).
  • FR DLCI
  • ATM VC

The following con depicts that a policy with a third-level grandchild non-queing policy is currently not supported on SIP-400.

Pseudo Policy:

parent

queuing

child

queuing

grand-child

Policing (No queuing allowed)

This feature is applicable on both ingress and egress QoS policy maps.
The following table shows the Triple Nesting QoS support over the various interfaces:
 
FLAT Policy
Parent Policy
Child Policy
Grandchild Policy
Ingress
Egress
Ingress
Egress
Ingress
Egress
Ingress
Egress
UDC
CD
UDC
CD
UDC
CD
UDC
CD
UDC
CD
UDC
CD
UDC
CD
UDC
CD

GIG main interface

shape

-

-

Yes

Yes

No

No

Yes

Yes

Yes

Yes

Yes

Yes

No

No

No

No

priority

No

No

Yes

Yes

No

No

No

No

Yes

Yes

Yes

Yes

No

No

No

No

band width

No

No

Yes

Yes

No

No

Yes

Yes

No

No

Yes

Yes

No

No

No

No

policy

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

ip prec marking

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

GIG dot1Q/QinQ sub interface

shape

-

-

Yes

Yes

-

-

-

-

Yes

Yes

Yes

Yes

No

No

No

No

priority

No

No

Yes

Yes

No

No

No

No

Yes

Yes

Yes

Yes

No

No

No

No

band width

No

No

Yes

Yes

No

No

Yes

Yes

No

No

Yes

Yes

No

No

No

No

policy

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

ip prec marking

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

EVC

shape

Yes

Yes

Yes

Yes

-

-

-

-

Yes

Yes

Yes

Yes

No

No

No

No

priority

No

No

Yes

Yes

No

No

No

No

Yes

Yes

Yes

Yes

No

No

No

No

band width

No

No

Yes

Yes

No

No

Yes

Yes

No

No

Yes

Yes

No

No

No

No

policy

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

ip prec marking

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

ISG

shape

No

No

No

Yes

No

No

No

Yes

No

No

Yes

Yes

No

No

No

No

priority

No

No

No

Yes

No

No

No

No

No

No

Yes

Yes

No

No

No

No

band width

No

No

No

Yes

No

No

No

Yes

No

No

Yes

Yes

No

No

No

No

policy

Yes

Yes

No

Yes

Yes

Yes

No

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

ip prec marking

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Channelized interface (SONET/SDH such as the 1-Port Channelized OC-3/STM-1 SPA)

shape

No

No

Yes

Yes

No

No

Yes

Yes

No

No

Yes

Yes

No

No

No

No

priority

No

No

Yes

Yes

No

No

No

No

No

No

Yes

Yes

No

No

No

No

band width

No

No

Yes

Yes

No

No

Yes

Yes

No

No

Yes

Yes

No

No

No

No

policy

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

ip prec marking

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

POS with FR

shape

No

No

Yes

Yes

No

No

Yes

Yes

No

No

Yes

Yes

No

No

No

No

priority

No

No

Yes

Yes

No

No

No

No

No

No

Yes

Yes

No

No

No

No

band width

No

No

Yes

Yes

No

No

Yes

Yes

No

No

Yes

Yes

No

No

No

No

policy

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

ip prec marking

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

ATM PVC

shape

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

priority

No

No

Yes

Yes

No

No

No

No

No

No

No

No

No

No

No

No

band width

No

No

Yes

Yes

No

No

No

No

No

No

No

No

No

No

No

No

policy

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

ip prec marking

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Configuration and Restrictions

  • Queuing Support on third level policy map
  • ATM SPA doesn't support Hierarchical queuing
  • Any service-policy supporting existing features on eother the ingress or the egress side, can have an extra level of policer in ingress or egress side too. This policer can be applied on a user-defined class or class-default in the third level of policy-map.
  • If a hierarchical policy-map is applied to subniterface, then the parent class has to be class-default

Configuration procedure

SUMMARY STEPS


Step 1 service-policy output Parent

Step 2 service-policy ingress_policy

Step 3 service-policy input third ingress_policy_level

DETAILED STEPS

Command
Purpose

Router(config-if)# service-policy output Parent

Example:

Router(config-if)# service-policy output Parent-155M

Applies this service-policy to an interface on the egress side

Router(config-if)# service-policy ingress_policy

Example:

Router(config-if)# service-policy ingress_policy

Applies this service-policy to an interface on the ingress side

Router(config-if)# service-policy input third ingress_policy_level

Example:

Router(config-if)# service-policy input ingress-three

Specifies that the service-policy applied on the ingress side is a grandchild level policy

Configuration Samples

Example of Third Level User Defined Egress QoS Policy-Map

policy-map NMC_POLICING

class NMC_RP

police 8000 8000 8000

conform-action set-dscp-transmit cs6

exceed-action set-dscp-transmit cs6

class NMC_SNMP

police cir 8000 bc 8000 be 8000

conform-action set-dscp-transmit af21

exceed-action set-dscp-transmit af21

policy-map CE_EGRESS_QUEUING

class NMC

bandwidth remaining percent 1

service-policy NMC_POLICING Level THREE Policy-map - Only policing

policy-map Parent-155M Level ONE Policy-map

class class-default

shape average 147712000

service-policy CE_EGRESS_QUEUING <<<< Level TWO Policy-map

Applying this service-policy to a Main interface

interface GigabitEthernet1/3/0

service-policy output Parent-155M

Applying this service-policy to a Sub interface

interface GigabitEthernet1/2/1.100

encapsulation dot1Q 456

service-policy output Parent-155M

Applying this service-policy to FR DLCI

interface Serial7/3/0/1:10

encapsulation frame-relay IETF

frame-relay interface-dlci 20

service-policy output Parent-155M

Applying this service-policy to EVC

interface GigabitEthernet1/3/0

service instance 51 ethernet

encapsulation dot1q 51

service-policy output Parent-155M

Example of Third Level User Defined Ingress QoS Policy-Map

policy-map ingress-one

class COS3

police cir 10240000 bc 1280000

conform-action set-dscp-transmit af21

exceed-action set-dscp-transmit af22

policy-map ingress-two

class NMC

shape average 10000000

service-policy ingress-one

policy-map ingress-three

class COS1

shape average 10000

service-policy ingress-two

Applying this service-policy to a Main interface

interface GigabitEthernet1/2/0

no ip address

negotiation auto

service-policy input ingress-three

Example of Third Level User Defined QoS Policy-Map for ATM

policy-map tnq2

class class-default

police 400000

policy-map tnq1

class video

police 300000

service-policy tnq2

policy-map tnq

class tnq

police 10000000

service-policy tnq1

Applying this service-policy to a ATM PVC

interface ATM1/0/0

no ip address

no atm enable-ilmi-trap

pvc 10/100

service-policy out tnq

Configuring IGMP Snooping on a SIP-200

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.


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


NoteWhen 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

SIP-200/SPA

This feature is supported on SIP-200 for the following SPAs:

  • 2-Port and 4-Port Channelized T3 SPA
  • 8-Port Channelized T1/E1 SPA
  • 1-Port Channelized OC3/STM-1 SPA

Configuring ACFC and PFC Support

The following sections list the configuration tasks for ACFC and PFC handling.

Configuring ACFC Support

SUMMARY STEPS

Use the following summary of commands to configure the ACFC.


Step 1 enable

Step 2 configure terminal

Step 3 interface serial slot / subslot / port : channel-group

Step 4 shutdown

Step 5 ppp acfc remote { apply | reject | ignore }

Step 6 ppp acfc local { request | forbid }

Step 7 no shutdown

DETAILED STEPS

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


Example:

Router(config)# interface serial 2/1/0 : 2

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 }

Example:

Router(config-if)# ppp acfc remote apply

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 }

Example:

Router(config-if)# ppp acfc local request

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

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

Step 7

Router(config-if)# no shutdown

Reenables the interface.


ACFC Configuration Example

The following example configures the interface to accept ACFC requests from a remote peer and perform ACFC on frames sent to the peer, and include the ACFC option in its outbound configuration in its outbound configuration requests:

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

Configuring PFC Support

SUMMARY STEPS

Use the following summary of commands to configure the PFC.


Step 1 enable

Step 2 configure terminal

Step 3 interface serial slot / subslot / port : channel-group

Step 4 shutdown

Step 5 ppp pfc remote { apply | reject | ignore }

Step 6 ppp pfc local { request | forbid }

Step 7 no shutdown

DETAILED STEPS

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

Example:

Router(config)# interface serial 3/0/0:0

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 }

Example:

Router(config-if)# ppp pfc remote apply

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 }

Example:

Router(config-if)# ppp pfc local 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 PPPoEoE on a Cisco 7600 SIP-400

Point-to-Point Protocol (PPP) provides a standard method of communicating to peers over a point-to-point link. An Ethernet link provides multipoint communication between multiple peers. PPP over Ethernet (PPPoE) allows point-to-point communication across multipoint Ethernet links.

The PPPoE over Ethernet interface (PPPoEoE) enables the Cisco 7600 series router with Cisco 7600 SIP-400 to terminate Ethernet PPP sessions over Ethernet links. The PPPoE over IEEE 802.1Q VLANs feature enables the router to terminate Ethernet PPP sessions across VLAN links. IEEE 802.1Q encapsulation is used to interconnect a VLAN-capable router with another VLAN-capable networking device. The packets on the 802.1Q link contain a standard Ethernet frame and the VLAN information associated with that frame.

Supported Features

PPPoEoE on the Cisco 7600 SIP-400 supports the following features:

  • PPPoE discovery packets (rate-limited), PPPoE PPP control packets, and PPPoE PPP IP data packets provide a per-user session on an Ethernet interface.
  • PPPoE is supported on main interfaces, 802.1Q and QinQ access interfaces, and VLAN ranges (802.1Q ranges and QinQ inner ranges).
  • 8 K PPPoE sessions are supported.
  • PPPoE and IP sessions can be configured on the same subinterface.

Limitations and Restrictions

PPPoEoE on the Cisco 7600 SIP-400 has the following limitations and restrictions:

  • PPP over ATM (PPPoA) is not supported.
  • Tunneling of PPPoE sessions (Level 2 Tunneling Protocol) is not supported.
  • Ambiguous VLANs and a range of VLANs for IP session interfaces are not supported. However, a range of VLANs is supported for PPPoE-configured interfaces.
  • Negotiated maximum transmission unit (MTU) value can only be 1492 or 1500 bytes.
  • If the ip tcp adjust-mss command is used, the only value supported is 1468.
  • PPPoE can only be configured on subinterfaces using the access keyword.

Configuring a Virtual Template Interface

Configure a virtual template before you configure PPPoE on an Ethernet interface. The virtual template interface is a logical entity that is applied dynamically as needed to an incoming PPP session request.

SUMMARY STEPS


Step 1 interface virtual-template number

Step 2 ip unnumbered ethernet number

Step 3 mtu bytes

Step 4 ppp authentication chap

Step 5 ppp ipcp ip address required

DETAILED STEPS

To create and configure a virtual template interface, enter the following commands beginning in global configuration mode:

 

Command or Action
Purpose

Step 1

Router(config)# interface virtual-template number

Creates a virtual template interface and enters interface configuration mode.

Step 2

Router(config-if)# ip unnumbered ethernet number

Enables IP without assigning a specific IP address on the LAN.

Step 3

Router(config-if)# mtu bytes

(Optional) Sets the maximum MTU size for the interface.

Note MTU size can be set only to 1492 or 1500.

Step 4

Router(config-if)# ppp authentication chap

Enables PPP authentication on the virtual template interface.

Step 5

Router(config-if)# ppp ipcp ip address required

Required for legacy dial-up and DSL networks. Prevents a PPP session from being set up with 0.0.0.0 remote ip address.

The following example shows the configuration of a virtual template interface:

Router(config)# interface virtual-template 1
Router(config-if)# ip unnumbered ethernet 21
Router(config-if)# no peer default ip address
Router(config-if)# ppp authentication chap
Router(config-if)# ppp authorization vpn1
Router(config-if)# ppp accounting vpn1
 

NoteThe PPP commands shown in these examples are typical of virtual template configurations. Not all PPP commands are required. Refer to the PPP documentation for more information.


Monitoring and Maintaining a Virtual Access Interface

When a virtual template interface is applied dynamically to an incoming user session, a virtual access interface (VAI) is created. You cannot use the command line interface (CLI) to directly create or configure a VAI, but you can display and clear the VAI by using the following commands in privileged EXEC mode.

SUMMARY STEPS


Step 1 clear interface virtual-access number

DETAILED STEPS

 

Command or Action
Purpose

Router# show interfaces virtual-access number configuration

Displays the configuration of the active VAI that was created using a virtual template interface.

The configuration keyword restricts output to configuration information.

Router# clear interface virtual-access number

Tears down the live sessions and frees the memory for other client users.

The following example shows how to display the active VAI configuration:

Router# show interfaces virtual-access 1.1 configuration
!
interface virtual-access1.1
if vrf forwarding vrf-1
ip unnumbered Loopback1
no ip proxy-arp
peer default ip address pool vrf-1
ppp authentication chap
end
 

NoteVirtual-access 1.1 is a PPPoE subinterface.


The following example shows how to clear a live session:

Router# clear interface virtual-access 1.1
Router#
 

Creating an Ethernet Interface and Enabling PPPoE

SUMMARY STEPS


Step 1 interface gigabitethernet number

Step 2 protocol pppoe group group-name

DETAILED STEPS

To create an Ethernet interface and enable PPPoE on it, enter the following commands beginning in global configuration mode:

 

Command or Action
Purpose

Step 1

Router(config)# interface gigabitethernet number

Creates an Ethernet interface and enters interface configuration mode.

Step 2

Router(config-if)# protocol pppoe group group-name

Enables PPPoE and allows PPPoE sessions to be created through that interface.

Configuring PPPoE in a BBA Group


NoteCisco IOS Release 12.2(33)SRC does not support the configuration of BBA groups using RADIUS. You must configure BBA groups manually.


SUMMARY STEPS


Step 1 bba-group pppoe name

Step 2 virtual-template template-number

Step 3 pppoe limit per-mac per-mac-limit

Step 4 pppoe limit max-sessions number

Step 5 pppoe limit per-vc per-vc-limit

Step 6 exit

Step 7 interface type number access

Step 8 encapsulation dot1q vlan-id

Step 9 pppoe enable group group-name

DETAILED STEPS

To configure a broadband aggregation (BBA) group for PPPoE and link it to the appropriate virtual template interface, enter the following commands beginning in global configuration mode:

 

Command or Action
Purpose

Step 1

Router(config)# bba-group pppoe name

Configures a BBA group to be used to establish PPPoE sessions.

name identifies the BBA group. You can have multiple BBA groups.

Step 2

Router(config-bba)# virtual-template template-number

Specifies the virtual template interface to use to clone VAIs.

Step 3

Router(config-bba)# pppoe limit per-mac per-mac-limit

(Optional) Specifies the maximum number of sessions per MAC address for each PPPoE port that uses the group.

Step 4

Router(config-bba)# pppoe limit max-sessions number

(Optional) Specifies the maximum number of PPPoE sessions that can be terminated on this router from all interfaces.

Step 5

Router(config-bba)# pppoe limit per-vc per-vc-limit

(Optional) Specifies the maximum number of PPPoE sessions for each VC that uses the group.

Step 6

Router(config-bba)# exit

Returns to global configuration mode.

Step 7

Router(config)# interface type number access

Specifies the type of interface to which you want to attach the BBA group and enters interface configuration mode.

Note The access keyword is required on subinterfaces, but must not be used for main interfaces.

Step 8

Router(config-if)# encapsulation dot1q vlan-id

Enables IEEE 802.1Q encapsulation of traffic on a specified subinterface in a VLAN. Specify the VLAN identifier.

Note This step is required only for 802.1Q and QinQ interfaces.

Step 9

Router(config-if)# pppoe enable group group-name

Attaches the BBA group to the VLAN.

Configuring PPPoE over 802.1Q VLANs on a Cisco 7600 SIP-400

PPPoE over IEEE 802.1Q VLANs enables the Cisco 7600 series router with the SIP-400 to support PPPoE over IEEE 802.1Q encapsulated VLAN interfaces. IEEE 802.1Q encapsulation is used to interconnect a VLAN-capable router with another VLAN-capable networking device. The packets on the 802.1Q link contain a standard Ethernet frame and the VLAN information associated with that frame.


NotePPPoE is disabled by default on a VLAN.


Configuring a Virtual Template

Before configuring PPPoE on an IEEE 802.1Q VLAN interface, configure a virtual template and a BBA group. See the “Configuring a Virtual Template Interface” section, and the “Configuring PPPoE in a BBA Group” section.

Creating an Ethernet IEEE 802.1Q Encapsulated Subinterface and Enabling PPPoE

SUMMARY STEPS


Step 1 interface gigabitethernet slot / subslot / port.number access

Step 2 encapsulation dot1q vlan-id [ second-dot1q inner-vlan-id ]

Step 3 pppoe enable group group-name

DETAILED STEPS

To create an Ethernet 802.1Q interface and enable PPPoE on it, enter the following commands beginning in global configuration mode.

 

Command or Action
Purpose

Step 1

Router(config)# interface gigabitethernet slot / subslot / port.number access

Creates a Gigabit Ethernet subinterface and enters subinterface configuration mode.

Step 2

Router(config-subif) # encapsulation dot1q vlan-id [ second-dot1q inner-vlan-id ]

Enables IEEE 802.1Q encapsulation on a specified subinterface in VLANs.

Step 3

Router(config-subif)# pppoe enable group group-name

Enables PPPoE and allows PPPoE sessions to be created through the specified subinterface.

Verifying PPPoE over Ethernet and IEEE 802.1Q VLAN

To verify PPPoEoE and IEEE 802.1Q VLAN, enter the following commands in privileged EXEC mode:

Command or Action
Purpose

Router# show pppoe session all

Displays PPPoE session information for each session ID.

Router# show pppoe session packets

Displays PPPoE session statistics.

Router# show pppoe summary

Displays PPPoE summary statistics.

Clearing PPPoE Sessions

To clear PPPoE sessions, enter the following commands in privileged EXEC mode:

Command or Action
Purpose

Router# clear pppoe all

Clears all PPPoE sessions.

Router# clear pppoe interface

Clears all PPPoE sessions on a physical interface or subinterface.

Router# clear pppoe rmac

Clears PPPoE sessions from a client host MAC address.

Router# pppoe interface interface vlan vlan-number

Clears sessions on a per-VLAN basis in ambiguous VLAN cases.

Configuring Source IPv4 and Source MAC Address Binding on the SIP-400

The Source IPv4 and Source MAC Address Binding feature is used in conjunction with the DHCP Authorized ARP and Secure ARP features to provide a check of the source IPv4 and source MAC address binding information before a packet can proceed to a higher level of processing. If the binding information does not exist, the packet is dropped.

Configuration Guidelines

When configuring source IPv4 and source MAC address binding, follow these guidelines:

  • Supports access subinterfaces on the Cisco 7600 series routers in DHCP and non-DHCP environments.

Note Static entry of the MAC and IP address is required in a non-DHCP environment.


  • Supports IPv4 unicast packets only.
  • Supports Ethernet interfaces, subinterfaces, and routed Switched Virtual Interfaces (SVIs).
  • Supports interface/subinterface and intelligent edge (iEdge) IP sessions.
  • Supports up to 128000 IPv4 and MAC address bindings (subscriber entries) for the Cisco 7600 series router, and 8000 MAC address subscriber entries for each Cisco 7600 SIP-400.
  • This feature is recommended primarily for access-facing interfaces and subinterfaces.
  • Supports Cisco 7600 series router with RSP720, SUP720, or SUP 32.
  • Supports on Cisco 7600 SIP-400 for the following Ethernet SPAs:

2-Port Gigabit Ethernet SPA

5-Port Gigabit Ethernet SPA

10-Port Gigabit Ethernet SPA

  • Supports only Ethernet and Ethernet logical interfaces. This feature can be supported on other interfaces provided they have Ethernet encapsulations underneath their primary encapsulation (for example, RBE or routed bridged PVC or EVC).
  • If you are using EVC, this feature must be configured for bridge domain.

Restrictions

When configuring source IPv4 and source MAC address binding, note these restrictions:

  • This feature cannot be used if multiple clients are using the same MAC address and they are on the same logical interfaces (VLAN).
  • This feature does not support native LAN cards on the Cisco 7600 series router.
  • This feature supports only one EVC per SVI.

Securing ARP Table Entries to DHCP Leases

This task describes how to secure ARP table entries to DHCP leases, starting in global configuration mode.

SUMMARY STEPS


Step 1 configure terminal

Step 2 ip dhcp pool pool-name

Step 3 network network-number

Step 4 update arp

Step 5 exit

DETAILED STEPS

 

Command
Purpose

Step 1

Router# configure terminal

Enters global configuration mode.

Step 2

Router(config)# ip dhcp pool pool-name

Configures a DHCP address pool and enters DHCP pool configuration mode.

pool-name —Name of the pool. Can either be a symbolic string or an integer.

Step 3

Router(dhcp-config)# network network-number

Configures the network number and mask for a DHCP address pool.

network-number —IP address of the primary DHCP address pool.

Note Use the network command to configure the Cisco 7600 series router as a DHCP server. Otherwise, the Cisco 7600 acts as a DHCP relay agent and gets the address from an outside server.

Step 4

Router(dhcp-config)# update arp

Secures insecure ARP table entries to the corresponding DHCP leases.

Step 5

Router(dhcp-config)# exit

Exits DHCP pool configuration mode.

Example:

Router# configure terminal
Router(config)# ip dhcp pool tc10
Router(dhcp-config)# network 10.0.0.0 255.255.255.0
Router(dhcp-config)# update arp
Router(dhcp-config)# exit

Configuring the Interfaces for Source IPv4 and Source MAC Address Binding

This task describes how to enable source IPv4 and source MAC address binding in interface configuration mode.

SUMMARY STEPS


Step 1 configure terminal

Step 2 interface vlan vlan-number

Step 3 ip address ip-address mask

Step 4 ip verify unicast source reachable-via rx l2-src

Step 5 no shutdown

DETAILED STEPS

 

Command
Purpose

Step 1

Router# configure terminal

Enters global configuration mode.

Step 2

Router(config)# interface vlan vlan-number

Specifies interface and VLAN number and enters interface configuration mode.

vlan-number —Range is from 1 to 4094.

Note To configure a main interface, use the interface type slot/subslot/port command in global configuration mode.

Step 3

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

Sets an IP address for an interface.

ip-address —IP address.
mask —Mask for the associated subnet.

Step 4

Router(config-if)# ip verify unicast source reachable-via rx l2-src

Enables source IPv4 and source MAC address binding.

Step 5

Router(config-if)# no shutdown

Enables the interface.

Example:

Router# configure terminal
Router(config)# interface vlan 10
Router(config-if)# ip address 10.0.0.1 255.255.255.0
Router(config-if)# ip verify unicast source reachable-via rx l2-src
Router(config-if)# no shutdown

Configuring DHCP Authorized ARP

This task describes how to disable dynamic ARP learning on an interface, starting in interface configuration mode.

SUMMARY STEPS


Step 1 configure terminal

Step 2 interface type slot / subslot / port

Step 3 arp authorized

Step 4 arp timeout seconds

Step 5 service instance id ethernet

Step 6 encapsulation dot1q vlan-id

Step 7 rewrite ingress tag pop { 1 | 2} symmetric

Step 8 bridge-domain bridge-id

Step 9 no shutdown

Step 10 exit

DETAILED STEPS

 

Command
Purpose

Step 1

Router# configure terminal

Enters global configuration mode.

Step 2

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

Configures an interface type and enters interface configuration mode.

type slot / subslot / port —Specifies the type and location of the interface.

Step 3

Router(config-if)# arp authorized

Disables dynamic ARP learning on an interface.

Step 4

Router(config-if)# arp timeout seconds

Configures how long an entry remains in the ARP cache.

seconds —Time (in seconds) that an entry remains in the ARP cache. A value of 0 means that entries are never cleared from the cache.

Step 5

Router(config-if)# service instance id ethernet

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

id —Integer in the range of 1 to 4294967295 that uniquely identifies a service instance on an interface.

Step 6

Router(config-if-srv)# encapsulation dot1q vlan-id

Defines the matching criteria to map 802.1Q frames ingress on an interface to the appropriate service instance.

vlan-id —VLAN ID, an integer in the range 1 to 4094.

Step 7

Router(config-if-srv)# rewrite ingress tag pop { 1 | 2} symmetric

Specifies the encapsulation adjustment to be performed on the frame ingress to the service instance.

pop {1 | 2} —One or two tags are removed from the packet.
symmetric —(Optional) Specifies tagging on the packets in the reverse direction (egress).

Step 8

Router(config-if-serv)# bridge-domain bridge-id

Binds the service instance to a bridge domain instance.

bridge-id —Identifier for the bridge domain instance, an integer in the range of 1 to a platform-specific upper limit.

Step 9

Router(config-if-srv)# no shutdown

Enables the interface.

Step 10

Router(config-if-srv)# end

Ends the current configuration session and returns to privileged EXEC mode.

Example:

Router# configure terminal
Router(config)# interface gigabitethernet 8/0/1
Router(config-if)# arp authorized
Router(config-if)# arp timeout 60
Router(config-if)# service instance 101 ethernet
Router(config-if-srv)# encapsulation dot1q 101
Router(config-if-srv)# rewrite ingress tag pop 1 symmetric
Router(config-if-srv)# bridge-domain 10
Router(config-if-srv)# no shutdown
Router(config-if-srv)# end

Showing the Number of Dropped Packets

This task describes how to display the number of packets dropped when the source IPv4 and source MAC address binding check has failed.

 

Command
Purpose

Step 1

Router# attach slot-number

Attaches to the SIP-400.

slot-number —location of SIP-400.

Step 2

SIP-400-8# show platform drops detail

(Router prompt changes to SIP-400 prompt.) Shows statistics regarding dropped packets.

Example”

Router# attach 8
Entering CONSOLE for slot 8
Type “^C^C^C” to end this session
 
SIP-400-8# show platform drops detail
 
Global drops:
Drops for all interfaces:
Gi8/0/0 ENP ifixp 16 Source masking (normal occurrence)
Gi8/0/1 INP ifixp 3 BPDUs are not supported on this i/f
Gi8/0/1 ENP ifixp 2008 Source masking (normal occurrence)
Gi8/0/1 INP ifixp 2000 Src IP/MAC check failed
Gi8/0/1 ENP ifixp 13 Source masking (normal occurrence)
 

SIP-400-8#

Resetting a SIP

To reset a SIP, use the following command in privileged EXEC configuration mode:

 

Command
Purpose

Router# hw-module module slot reset

Turns power off and on to the SIP in the specified slot, where:

  • slot— Specifies the chassis slot number where the SIP is installed.

Configuration Examples

This section includes the following examples for configuring SIPs installed in a Cisco 7600 series router:

Layer 2 Interworking Configuration Examples

This section includes the following Layer 2 interworking configuration examples:

BCP in Trunk Mode Configuration Example

The following example shows how to configure BCP in trunk mode:

! Enter global configuration mode.
!
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
!
! Specify the interface address.
!
Router(config)# interface pos4/1/0
!
! Put the interface in Layer 2 mode for Layer 2 configuration.
 
Router(config-if)# switchport
%Please shut/no shut POS4/1/0 to bring up BCP
!
! When the switchport command is configured, the interface is automatically configured for ! trunk mode and nonegotiate status.
! Restart the interface to enable BCP.
!
Router(config-if)# shutdown
Router(config-if)# no shutdown
!
! Enable all VLANs for receiving and transmitting traffic on the trunk.
!
Router(config-if)# switchport trunk allowed vlan all
%Internal vlans not available for bridging:1006-1018,1021
 

The following example shows sample output from the show running-config command for this configuration. The switchport mode trunk and switchport nonegotiate commands are automatically NVgened when the switchport command is configured:

Router# show running-config interface pos4/1/0
Building configuration...
Current configuration : 191 bytes
!
interface POS4/1/0
switchport
switchport trunk allowed vlan all
switchport mode trunk
switchport nonegotiate
no ip address
encapsulation ppp
clock source internal
end

BCP in Single-VLAN Mode Configuration Example

The following example shows how to configure BCP in single-VLAN mode:

! Enter global configuration mode.
!
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
!
! Specify the interface address
!
Router(config)# interface pos4/1/0
!
! Disable IP processing on the interface. This is recommended for BCP interfaces.
!
Router(config-if)# no ip address
!
! Configure PPP encapsulation. You must configure PPP encapsulation before using the
! bridge-domain command.
!
Router(config-if)# encapsulation ppp
!
! Configure the bridging domain tag all Ethernet frames on the BCP link with the 802.1Q
! header.
!
Router(config-if)# bridge-domain 100 dot1q
%Please shut/no shut POS4/1/0 to bring up BCP
!
! Restart the interface to enable BCP.
!
Router(config-if)# shutdown
Router(config-if)# no shutdown
 

The following example shows sample output from the show running-config command for this configuration:

Router# show running-config interface pos4/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
 

The following example shows an example of the message that is sent if you attempt to configure the bridge-domain command without configuring PPP encapsulation:

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

MPLS Configuration Examples

This section includes the following MPLS configuration examples:

Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Class-Based Tunnel Selection (CBTS) Configuration Example

The following example shows how to configure Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Class-Based Tunnel Selection (CBTS). Tunnel1, Tunnel2, and Tunnel3 are member tunnels, and Tunnel4 is the master tunnel.

Router(config)# interface Tunnel1
Router(config-if)# ip unnumbered loopback0
Router(config-if)# interface destination 24.1.1.1
Router(config-if)# tunnel mode mpls traffic-eng
Router(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000
Router(config-if)# tunnel mpls traffic-eng exp 5
 
Router(config)# interface Tunnel2
Router(config-if)# ip unnumbered loopback0
Router(config-if)# interface destination 24.1.1.1
Router(config-if)# tunnel mode mpls traffic-eng
Router(config-if)# tunnel mpls traffic-eng bandwidth 50000
Router(config-if)# tunnel mpls traffic-eng exp 3 4
 
Router(config)# interface Tunnel3
Router(config-if)# ip unnumbered loopback0
Router(config-if)# interface destination 24.1.1.1
Router(config-if)# tunnel mode mpls traffic-eng
Router(config-if)# tunnel mpls traffic-eng bandwidth 10000
Router(config-if)# tunnel mpls traffic-eng exp default
 
Router(config)# interface Tunnel4
Router(config-if)# interface destination 24.1.1.1
Router(config-if)# tunnel mpls traffic-eng exp-bundle master
Router(config-if)# tunnel mpls traffic-eng exp-bundle member Tunnel1
Router(config-if)# tunnel mpls traffic-eng exp-bundle member Tunnel2
Router(config-if)# tunnel mpls traffic-eng exp-bundle member Tunnel3

Router(config-if)# tunnel mpls traffic-eng autoroute enable

QoS Configuration Examples

This section includes the following QoS configuration examples:

QoS with Multipoint Bridging Configuration Examples

The SIPs and SPAs support a subset of QoS features with MPB configurations.

  • For ATM bridging, Frame Relay bridging, MPB, and BCP features on the Cisco 7600 SIP-200 and Cisco 7600 SIP-400, these matching features are supported on bridged frames beginning in Cisco IOS Release 12.2(33)SRA:

Matching on ATM CLP bit

Matching on Frame Relay DE bit

Matching on Frame Relay DLCI

Matching on inner VLAN

Matching on inner CoS

Matching on IP DSCP (input interface only)

  • For ATM bridging, Frame Relay bridging, MPB, and BCP features on the Cisco 7600 SIP-200 and Cisco 7600 SIP-400, these marking features are supported on bridged frames beginning in Cisco IOS Release 12.2(33)SRA:

Set ATM CLP bit (output interface only)

Set Frame Relay DE bit (output interface only)

Set inner CoS

  • For ATM bridging, Frame Relay bridging, MPB, and BCP features on the Cisco 7600 SIP-200 and Cisco 7600 SIP-400, the following marking features with policing are supported on bridged frames beginning in Cisco IOS Release 12.2(33)SRA:

Set inner CoS

For more information about configuring QoS on SIPs and SPAs, see the “Configuring QoS Features on a SIP” section.

This section includes the following QoS with MPB configuration examples:

Matching All Traffic on an Inner VLAN Tag with MPB on SIPs and SPAs on the Cisco 7600 Series Router Example

You can match traffic on an inner VLAN ID of a packet when you are using bridging features on a SPA. The following example shows configuration of a QoS class that filters all bridged traffic for VLAN 100 into a class named “vlan-inner-100.” An output service policy is then applied to the SPA interface that bridges all outgoing traffic for the vlan-inner-100 class into VLAN 100.

! Configure the class maps with your matching criteria.
!
Router(config)# class-map match-all vlan-inner-100
Router(config-cmap)# match vlan inner 100
!
! Apply the service policy to an input or output bridged interface or VC.
!
Router(config)# interface atm3/0/0
Router(config-if)# pvc 100/100
Router(config-if-atm-vc)# bridge-domain 100 dot1q
Router(config-if-atm-vc)# service-policy output vlan-inner-100
Router(config-if)# end

Marking the Inner CoS Value with MPB on SIPs and SPAs on the Cisco 7600 Series Router Example

The following example shows configuration of a QoS class that filters all traffic matching on VLAN 100 into a class named “vlan-inner-100.” The configuration shows the definition of a policy-map (also named “vlan-inner-100”) that marks the inner CoS with a value of 3 for traffic in the vlan-inner-100 class. Since marking of the inner CoS value is only supported with bridging features, the configuration also shows the service policy being applied as an output policy to a serial SPA interface that bridges traffic into VLAN 100 using the bridge-domain command.

! Configure the class maps with your matching criteria.
!
Router(config)# class-map match-all vlan-inner-100
Router(config-cmap)# match vlan inner 100
Router(config-cmap)# exit
!
! Configure the policy map to mark all traffic in a class.
!
Router(config)# policy-map vlan-inner-100
Router(config-pmap)# class vlan-inner-100
Router(config-pmap-c)# set cos-inner 3
Router(config-pmap-c)# exit
Router(config-pmap)# exit
!
! Apply the service policy to an input or output bridged interface or VC.
!
Router(config)# interface serial3/0/0
Router(config-if)# no ip address
Router(config_if)# encapsulation ppp
Router(config-if)# bridge-domain 100 dot1q
Router(config-if)# service-policy output vlan-inner-100
Router(config-if)# shutdown
Router(config-if)# no shutdown
Router(config-if)# end

Configuring QoS Matching, Shaping, and Marking with MPB on SIPs and SPAs on the Cisco 7600 Series Router Example

The following example shows a complete QoS configuration of matching, shaping, and marking with MPB on SIPs and SPAs.

! Configure the class maps with your matching criteria.
! The following class maps configure matching on the inner VLAN ID.
!
Router(config)# class-map match-all vlan100
Router(config-cmap)# match vlan inner 100
Router(config-cmap)# exit
Router(config)# class-map match-all vlan200
Router(config-cmap)# match vlan inner 200
Router(config-cmap)# exit
Router(config)# class-map match-all vlan300
Router(config-cmap)# match vlan inner 300
Router(config-cmap)# exit
!
! The following class maps configure matching on the inner CoS value.
!
Router(config)# class-map match-all cos0
Router(config-cmap)# match cos inner 0
Router(config-cmap)# exit
Router(config)# class-map match-all cos1
Router(config-cmap)# match cos inner 1
Router(config-cmap)# exit
Router(config)# class-map match-all cos2
Router(config-cmap)# match cos inner 2
Router(config-cmap)# exit
Router(config)# class-map match-all cos7
Router(config-cmap)# match cos inner 7
Router(config-cmap)# exit
!
! Configure a policy map for the defined classes.
! The following policies define shaping characteristics for classes
! on different VLANs
!
Router(config)# policy-map vlan100
Router(config-pmap)# class cos1
Router(config-pmap-c)# bandwidth percent 10
Router(config-pmap-c)# exit
Router(config-pmap)# class cos2
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap-c)# exit
Router(config-pmap)# class cos7
Router(config-pmap-c)# percent 30
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# policy-map vlan200
Router(config-pmap)# class cos1
Router(config-pmap-c)# bandwidth percent 10
Router(config-pmap-c)# exit
Router(config-pmap)# class cos2
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap-c)# exit
Router(config-pmap)# class cos7
Router(config-pmap-c)# percent 30
Router(config-pmap-c)# exit
Router(config-pmap)# exit
!
! The following policy map defines criteria for an output interface using MPB
!
Router(config)# policy-map egress_mpb
Router(config-pmap)# class vlan100
Router(config-pmap-c)# bandwidth percent 30
Router(config-pmap-c)# service-policy vlan100
Router(config-pmap-c)# exit
Router(config-pmap)# class vlan200
Router(config-pmap-c)# bandwidth percent 40
Router(config-pmap-c)# service-policy vlan200
!
! The following policy map defines criteria for an input interface using MPB
!
Router(config)# policy-map ingress_mpb
Router(config-pmap)# class vlan100
Router(config-pmap-c)# set cos-inner 5
Router(config-pmap-c)# exit
Router(config-pmap)# class vlan200
Router(config-pmap-c)# set cos-inner 3
!
! The following policy map defines criteria for an ATM output interface using MPB
! Note: You can only mark ATM CLP on an ATM output interface with MPB
!
Router(config)# policy-map atm_clp
Router(config-pmap)# class cos1
Router(config-pmap-c)# set atm-clp
Router(config-pmap-c)# exit
Router(config-pmap)# class cos2
Router(config-pmap-c)# set atm-clp
Router(config-pmap-c)# exit
Router(config-pmap)# exit
!
! Configure an interface for MPB and apply the service policies.
! The following example configures a POS interface in BCP trunk mode and applies two
! different service policies for the output and input traffic on the interface.
!
Router(config)# interface POS3/0/0
Router(config-if)# switchport
Router(config-if)# shutdown
Router(config-if)# no shutdown
Router(config-if)# switchport trunk allowed vlan 100,200,300
Router(config-if)# service-policy output egress_mpb
Router(config-if)# service-policy input ingress_mpb
!
! The following example configures an ATM interface with bridging on VLAN 100
! and applies a service policy for setting the ATM CLP for the output traffic.
!
Router(config)# interface ATM 4/1/0
Router(config-if)# pvc 1/100
Router(config-if-atm-vc)# bridge-domain 100
Router(config-if-atm-vc)# service-policy output atm-clp

Setting the Inner CoS Value as a Policing Action for SIPs and SPAs on the Cisco 7600 Series Router Example

The following example shows configuration of a QoS class that filters all traffic for virtual LAN (VLAN) 100 into a class named “vlan-inner-100,” and establishes a traffic shaping policy for the vlan-inner-100 class. The service policy limits traffic to a CIR of 20 percent and a PIR of 40 percent, with a conform burst (bc) of 300 ms, and peak burst (be) of 400 ms, and sets the inner CoS value to 3. Because setting of the inner CoS value is only supported with bridging features, the configuration also shows the service policy being applied as an output policy for an ATM SPA interface permanent virtual circuit (PVC) that bridges traffic into VLAN 100 using the bridge-domain command.

! Configure the class maps with your matching criteria
!
Router(config)# class-map match-all vlan-inner-100
Router(config-cmap)# match vlan inner 100
Router(config-cmap)# exit
!
! Configure the policy map to police all traffic in a class and mark conforming traffic
! (marking traffic whose rate is less than the conform burst)
!
Router(config)# policy-map vlan-inner-100
Router(config-pmap-c)# police cir percent 20 bc 300 ms be 400 ms pir percent 40 conform-action set-cos-inner-transmit 3
Router(config-pmap-c)# exit
Router(config-pmap)# exit
!
! Apply the service policy to an input or output bridged interface or VC.
!
Router(config)# interface atm3/0/0
Router(config-if)# pvc 100/100
Router(config-if-atm-vc)# bridge-domain 100 dot1q
Router(config-if-atm-vc)# service-policy output vlan-inner-100
Router(config-if)# end

Hierarchical QoS with 2-Level Policy Map Configuration Examples

The following example shows configuration of hierarchical QoS that maps to two levels of hierarchical queues (you can configure up to three levels). The first-level policy (the parent policy) configures the aggregated data rate to be shaped to 1 Mbps for the class-default class. The second-level policy (the child policy) configures the traffic in User-A class for 40 percent of the bandwidth and traffic in User-B class for 60 percent of the bandwidth.

Because this example shows the parent policy applying to the class-default class, it is supported in Cisco IOS Release 12.2(33)SXF and later, as well as in Cisco IOS Release 12.2(33)SRA.

! Configure the class maps with your matching criteria
!
Router(config)# class-map match-any User-A
Router(config-cmap)# match access-group A
Router(config-cmap)# exit
Router(config)# class-map match-any User-B
Router(config-cmap)# match access-group B
Router(config-cmap)# exit
!
! Configure the parent policy for class-default to shape
! all traffic in that class and apply a second-level policy.
!
Router(config)# policy-map parent
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape 1000000
Router(config-pmap-c)# service-policy child
Router(config-pmap-c)# exit
Router(config-pmap)# exit
!
! Configure the child policy to allocate different percentages of
! bandwidth by class.
!
Router(config)# policy-map Child
Router(config-pmap)# class User-A
Router(config-pmap-c)# bandwidth percent 40
Router(config-pmap-c)# exit
Router(config-pmap)# class User-B
Router(config-pmap-c)# bandwidth percent 60
Router(config-pmap-c)# exit
Router(config-pmap)# exit
!
! Apply the parent service policy to an input or output interface.
!
Router(config)# interface GigabitEthernet 2/0/0
Router(config-if)# service-policy output parent
 

The following example shows configuration of hierarchical QoS that maps to two levels of hierarchical queues, where the parent policy configures average traffic shaping rates on both user-defined classes as well as the class-default class, which is supported beginning in Cisco IOS Release 12.2(33)SRA. This configuration does not show the corresponding class map configuration, which also are required to support these policy maps.

! Configure the parent policy for user-defined and class-default classes to shape
! traffic in those classes and apply a second-level policy.
!
Router(config)# policy-map parent
Router(config-pmap)# class input-vlan100
Router(config-pmap-c)# shape average 100000
Router(config-pmap-c)# service-policy child-pm
Router(config-pmap-c)# exit
Router(config-pmap)# class input-vlan200
Router(config-pmap-c)# shape average 100000
Router(config-pmap-c)# service-policy child-pm
Router(config-pmap-c)# exit
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 200000
Router(config-pmap-c)# service-policy child-pm
Router(config-pmap-c)# exit
Router(config-pmap)# exit
!
! Configure the child policy to allocate different percentages of
! bandwidth by class.
! </