Cisco 7600 Series Router SIP, SSC, and SPA Software Configuration Guide

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.

Note For 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.

Note The Cisco 7600 series router SIPs are not supported 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

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:

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:

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.

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.

Note For 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.

Note Effective 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.

This section includes the following topics:

• Overview of dMLFR
• dMLFR Configuration Guidelines
• dMLFR Configuration Tasks
• Verifying dMLFR

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 (required)
• Assigning an Interface to a dMLFR Bundle (required)

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:

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.

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.

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.

Note Based 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.

Note On 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.

This section includes the following topics:

• dMLPPP Configuration Guidelines
• dMLPPP Configuration Tasks
• Verifying dMLPPP

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 (required)
• Creating a dMLPPP Bundle (required)
• Assigning an Interface to a dMLPPP Bundle (required)
• Configuring Link Fragmentation and Interleaving over dMLPPP (optional)

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.

Note When 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:

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. Note To enable no 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.

Note 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 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. Note To enable no 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:

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

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.

Cisco 7600 Series Router LFI Restrictions

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

• A maximum number of 200 permanent virtual circuits (PVCs) or switched virtual circuits (SVCs) using Link Fragmentation and Interleaving (LFI) is supported for all ATM SPAs (or other ATM modules) in a Cisco 7600 series router.
• LFI using FRF.12 is supported in hardware only for the 2-Port and 4-Port Channelized T3 SPA and 8-Port Channelized T1/E1 SPA.
• LFI over dMLPPP is supported in software or hardware depending on your link configuration. For more information about software-based LFI over dMLPPP, see the “Configuring Link Fragmentation and Interleaving over dMLPPP” section. For more information about hardware-based LFI over dMLPPP, refer to the “Configuring the 8-Port Channelized T1/E1 SPA,” and Chapter20, “Configuring the 2-Port and 4-Port Channelized T3 SPAs”
• QoS is implemented on the Cisco 7600 SIP-200 for dLFI.

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

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. Note You 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.

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

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

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

Verifying the Configuration

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

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

Troubleshooting Tips

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.

Note Because 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)

Note FRF.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.

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)
• Configuring Multipoint Bridging
• Configuring Private Hosts over Virtual Private LAN Service (VPLS)

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 .

Note RFC 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.

Note The 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”

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.

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.

Note RFC 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

Note All 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.

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.

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

The following shows an example of each command:

Verification

Use these commands to verify operation.

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.

Note RFC 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

Note All 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)

Note ChOC-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:

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.

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:

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:

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:

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

Verifying the Private Hosts on the VPLS Configuration

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

Example

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

Table 5-9 Troubleshooting Scenarios for Private Host feature

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.

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:

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:

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

Note When switchport is configured, the encapsulation is automatically changed to PPP.

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:

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:

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.

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

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.

Note Once 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.

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

Note If 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.

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

MinTxInt: 500000, MinRxInt: 500000, Multiplier: 3

Min Echo interval: 0

Debugging the BFD Configuration

Use these debug commands to troubleshoot the BFD VCCV configuration.