Downloads |
Table Of Contents
VC Bundle Support and Bundle Management
Configuring IP to ATM CoS on a Single ATM VC
Defining the WRED Parameter Group
Configuring the WRED Parameter Group
Displaying the WRED Parameters
Displaying the Queueing Statistics
Configuring IP to ATM CoS on an ATM Bundle
Applying Bundle-Level Parameters
Configuring the Bundle-Level Parameters
Configuring VC Class Parameters to Apply to a Bundle
Applying Parameters to Individual VCs
Configuring a VC Bundle Member Directly
Configuring VC Class Parameters to Apply to a VC Bundle Member
Applying a VC Class to a Discrete VC Bundle Member
Configuring a VC Not to Accept Bumped Traffic
Monitoring and Maintaining VC Bundles and Their VC Members
Single ATM VC with WRED Group and IP Precedence Example
VC Bundle Configuration Using a VC Class Example
exponential-weighting-constant
IP to ATM Class of Service
This feature module describes the IP to ATM Class of Service feature. It contains the following sections:
Feature Overview
The IP to ATM Class of Service feature implements a solution for coarse-grained mapping of QoS characteristics between IP and ATM, using Cisco Enhanced ATM port adapters (PA-A3) on Cisco 7200 and 7500 series routers. (This category of coarse-grained QoS is often referred to as CoS). The resulting feature makes it possible to support differential services in network service provider environments.
IP to ATM CoS is designed to provide a true working solution to class-based services, without the investment of new ATM network infrastructures. Now networks can offer different service classes (sometimes termed differential service classes) across the entire WAN, not just the routed portion. Mission-critical applications can be given exceptional service during periods of high network usage and congestion. In addition, noncritical traffic can be restricted in its network usage, which ensures greater QoS for more important traffic and user types.
IP to ATM CoS supports configuration of the following:
•
Single ATM virtual circuits (VCs)
•
Single ATM VC Support
IP to ATM CoS support for a single ATM VC allows network managers to use existing features, such as committed access rate (CAR) or policy-based routing (PBR) to classify and mark different IP traffic by modifying the IP Precedence field in the IPv4 packet header. Subsequently, Weighted Random Early Detection (WRED) or Distributed WRED (DWRED) can be configured on a per-VC basis so that the IP traffic is subject to different drop probabilities (and therefore priorities) as IP traffic coming into a router competes for bandwidth on a particular VC.
Enhanced ATM port adapters (PA-A3) provide the ability to shape traffic on each VC according to the ATM service category and traffic parameters employed. When you use the IP to ATM CoS feature, congestion is managed entirely at the IP layer by WRED running on the routers at the edge of the ATM network.
illustrates the IP to ATM CoS support for a single ATM VC.
Figure 1 Single ATM Circuit Class
VC Bundle Support and Bundle Management
ATM VC bundle management allows you to configure multiple VCs that have different QoS characteristics between any pair of ATM-connected routers. As shown in , these VCs are grouped in a bundle and are referred to as bundle members.
Figure 2 ATM VC Bundle
ATM VC bundle management allows you to define an ATM VC bundle and add VCs to it. Each VC of a bundle has its own ATM traffic class and ATM traffic parameters. You can apply attributes and characteristics to discrete VC bundle members or you can apply them collectively at the bundle level.
Using VC bundles, you can create differentiated service by flexibly distributing IP Precedence levels over the different VC bundle members. You can map a single precedence level or a range of levels to each discrete VC in the bundle, thereby enabling individual VCs in the bundle to carry packets marked with different precedence levels. You can use WRED (or DWRED) to further differentiate service across traffic that has different IP Precedence but that uses the same VC in a bundle.
To determine which VC in the bundle to use to forward a packet to its destination, the ATM VC bundle management software matches precedence levels between packets and VCs (see ). IP traffic is sent to the next hop address for the bundle because all VCs in a bundle share the same destination, but the VC used to carry a packet depends on the value set for that packet in the IP Precedence bits of the type of service (ToS) byte of its header. The ATM VC bundle management software matches the IP Precedence of the packet to the IP Precedence value or range of values assigned to a VC, sending the packet out on the appropriate VC. Moreover, the ATM VC bundle management feature allows you to configure how traffic will be redirected when the VC the packet was matched to goes down. illustrates how the ATM VC bundle management software determines which PVC bundle member to use to carry a packet and how WRED (or DWRED) is used to differentiate traffic on the same VC.
Figure 3 ATM VC Bundle PVC Selection for Packet Transfer
The support of multiple parallel ATM VCs allows you to create stronger service differentiation at the IP layer. For instance, you might want to provide IP traffic belonging to real-time CoS (such as Voice over IP traffic) on an ATM VC with strict constraints (constant bit rate (CBR) or variable bit rate (VBR-rt), for example), while transporting traffic other than real-time traffic over a more elastic ATM available bit rate (ABR) permanent virtual circuit (PVC). Using a configuration such as this would allow you to fully utilize your network capacity. You could also elect to transport best-effort IP traffic over an unspecified bit rate (UBR) PVC—UBR is effectively the ATM version of best-effort service.
Benefits
The benefits of using the IP to ATM CoS feature include the following:
•
•
•
•
•
•
•
List of Terms and Acronyms
available bit rate (ABR)—An ATM service category in which the network may instruct sources to reduce their rate during times of congestion.
constant bit rate (CBR)—An ATM service category that aims to emulate a dedicated circuit of a certain fixed bandwidth.
IP Precedence—A 3-bit value in the ToS byte of the IPv4 packet header used by weighted random early detection (WRED) as a drop preference indicator.
permanent virtual circuit (PVC)—A virtual circuit that is permanently established. PVCs save bandwidth associated with circuit establishment and tear down processes in situations where certain virtual circuits must exist all the time. In ATM terminology, called a permanent virtual connection.
port adapter—Media-specific interface PCI daughter card for use on the virtual interface processor (VIP).
Random Early Detection (RED)—An algorithm that, when applied, specifies that a small percentage of packets are to be dropped when congestion is detected, that is, before the queue in question overflows completely.
type of service (ToS)—A byte in IPv4 packet header used, for example, by weighted random early detection (WRED) as a drop preference indicator.
uncommitted bit rate (UBR)—An ATM service category defined by the ATM Forum for best-effort traffic with no traffic-related service guarantees. No ATM traffic-related parameters are specified. A UBR circuit is by definition a best-effort circuit.
variable bit rate (VBR)—An ATM service category in which mean cell rate, peak cell rate, and burst tolerance are specified. A VBR circuit takes precedence over a UBR circuit in the event that there is contention for network resources.
virtual circuit (VC)—A logical circuit created to ensure reliable communication between two network devices. A VC is defined by a VPI/VCI pair, and can be either permanent (PVC) or switched (SVC). In ATM, a virtual circuit is called a virtual channel.
virtual channel identifier (VCI)—16-bit field in the header of an ATM cell. The VCI, together with the VPI, is used to identify the next destination of a cell as it passes through a series of ATM switches on its way to its destination.
Virtual Interface Processor (VIP)—Architecture for intelligent interface processors for the Cisco 7000 series routers. This architecture supports two port adapters, standard packet delivery, and distributed fast switching and feature offload.
virtual path identifier (VPI)—8-bit field in the header of an ATM cell. The VPI, together with the VCI, is used to identify the next destination of a cell as it passes through a series of ATM switches on its way to its destination.
Weighted Random Early Detection (WRED)—A variant of Random Early Detection (RED) in which the probability of a packet being dropped depends on its precedence, as well as other factors in the RED algorithm.
weighted fair queueing (WFQ)—A queueing algorithm that provides a fraction of link bandwidth (constituting the weight) to each of several queues.
Restrictions
Remember the following points when using this feature:
•
•
•
•
•
Supported Platforms
The IP to ATM CoS feature is supported on Cisco 2600, Cisco 3600, Cisco 7200, and Cisco 7500 series routers equipped with the following hardware:
•
•
•
•
•
•
•
•
Prerequisites
The IP to ATM CoS feature requires ATM PVC management and Cisco Express Forwarding (CEF) switching functionality.
Supported MIBs and RFCs
None
Functional Description
This section gives a broad overview of the IP to ATM CoS feature. It includes the following topics:
Why Use IP to ATM CoS?
Internet service classes can be identified and sorted within the router network. But as traffic traverses the wide-area ATM fabric, the relative ATM class definitions are not equivalent, and a traffic type may be treated differently in the ATM switching fabric than in the router network; mission-critical applications or data could be dropped during times of network congestion.
The IP to ATM Cos feature uses the Cisco Enhanced ATM port adapter (PA-A3) on Cisco 7500 and Cisco 7200 series routers to provide the ability to map IP CoS and ATM QoS, extending the capability previously available only for IP networks; differentiated services are preserved through the ATM network.
IP to ATM CoS Features
IP to ATM CoS includes the following features:
•
This feature enables queues to be maintained on a per-VC basis. Packets are queued and dequeued based on the back pressure from the PA. Use of a queue per VC prevents one or more congested VCs from affecting the traffic flow on other VCs that are not congested.
•
This feature applies the WRED algorithm independently to each per-VC queue. The WRED parameters are configurable on a per-VC basis so that congestion management can be configured as appropriate for each VC.
•
This feature maintains per-flow and per-VC statistics based on IP Precedence.
Congestion Avoidance
For each VC that is created on the Enhanced ATM port adapter (PA-A3), the PA allocates some of the buffers from its buffer pool to that VC in order to create a queue for that VC.
The use of per-VC queues ensures that a direct relationship exists between the outgoing ATM VC and the IP packets to be forwarded on that queue. This mechanism establishes a packet queue for each outgoing ATM VC. In this manner, should an ATM VC become congested, only the packet queue associated with that VC will begin to fill. If the queue overfills, then all other queues remain unaffected. Such a mechanism ensures that an individual VC cannot consume all of the resources of the router should only one of its outgoing VCs be congested or underprovisioned.
Queues for buffering more packets for a particular VC are created in the Layer 3 processor system and are mapped one-to-one to the per-VC queues on the PA. When the PA per-VC queues become congested, they signal back pressure to the Layer 3 processor; the Layer 3 processor can then continue to buffer packets for that VC in the corresponding Layer 3 queue. Furthermore, because the Layer 3 queues are accessible by the Layer 3 processor, a user can run flexible software scheduling algorithms on those queues.
When you transport data over ATM fabrics, it is essential that decisions to discard data (because of insufficient network resources or congestion) be made at the packet level. To do otherwise would be to send incomplete data packets into the ATM fabric, causing the packets to be discarded by either the ATM switched fabric (if it is equipped with early packet discard) or at the remote end where the packet will be reassembled and found to be incomplete.
To initiate effective congestion management techniques, IP to ATM CoS uses per-VC WRED (or DWRED). Per-VC WRED (or DWRED) selectively places TCP sessions in slow start to ensure higher aggregate throughput under congestion. shows low priority packets being dropped on VC1 because VC1 is congested. In this example, VC2 is not congested and all packets, regardless of priority, are transmitted.
Figure 4 Traffic Congestion with IP to ATM CoS and Per-VC WRED
Running the WRED algorithm independently on each per-VC queue provides differentiated QoS to traffic of different IP Precedence values.
Bumping and ATM VC Bundles
The ATM VC bundle is designed to behave as a single routing link to the destination router while managing the integrity of its group of circuits. The integrity of each circuit is maintained through individual monitoring. Should a circuit fail, appropriate action is taken, in the form of circuit bumping or bundle disabling.
VC integrity is maintained through ATM Operation, Administration, and Maintenance (OAM) polling mechanisms. These mechanisms will determine whether a VC is unavailable or severely congested. Should an individual circuit become unavailable, then the device consults a preset series of rules to determine what course of action to take next. These rules are defined by the Internet service provider (ISP) through configuration parameters.
conceptualizes a failed VC bundle member whose failure calls into effect the configured bumping rules.
Figure 5 VC Bundle Member Circuit Failure Enacting Bumping Rules
In the event of failure, the router responds with one of two methods. The first method dynamically assigns the traffic bound on the failed VC to an alternative VC. This is termed circuit bumping. Bumped traffic is then shared on an existing in-service VC. Traffic typically would be bumped from a higher class to a lower one, although it does not have to be. For example, should the premium, or first class, data circuit become unavailable, then all premium users would share the second class or general circuit. Preference would then be given to the premium traffic within this shared circuit.
The second method is to declare all circuits of the bundle to be down. In effect, the device is declaring the routed bundle inactive and asking the routing layer to search for an alternate.
The determination of whether to bump or whether to declare the bundle inactive is predefined by the network provider when administering the network configuration.
Configuration Tasks
You can configure IP to ATM CoS on either a single ATM VC, or on an ATM bundle. To configure IP to ATM CoS on a single ATM VC, perform the tasks in the following sections.
To configure IP to IP to ATM CoS on an ATM bundle, perform the tasks in the "Configuring IP to ATM CoS on an ATM Bundle" section later in this document.
Configuring IP to ATM CoS on a Single ATM VC
To configure IP to ATM CoS for a single ATM VC, perform the tasks in the following sections. The first two sections are required; the remaining sections are optional.
•
•
•
•
Defining the WRED Parameter Group
To define the Weighted Random Early Detection (WRED) parameter group, use the following command in global configuration mode:
random-detect-group group-name
Defines the WRED or VIP-Distributed WRED (DWRED) parameter group.
Configuring the WRED Parameter Group
To configure the exponential weight factor for the average queue size calculation for a WRED parameter group or to configure a WRED parameter group for a particular IP precedence, use the following commands beginning in global configuration mode:
1
random-detect-group group-name
Specifies the WRED or DWRED parameter group.
2
exponential-weighting-constant exponent
or
precedence precedence min-threshold max-threshold mark-probability-denominatorConfigures the exponential weight factor for the average queue size calculation for the specified WRED or DWRED parameter group.
or
Configures the specified WRED or DWRED parameter group for a particular IP Precedence.
Displaying the WRED Parameters
To display the configured WRED parameters, use the following command in privileged EXEC mode:
Displaying the Queueing Statistics
To display the queueing statistics of an interface, use the following command in privileged EXEC mode:
show queueing interface interface-number
[vc [[vpi/] vci]]Displays the queueing statistics of a specific VC on an interface.
Configuring IP to ATM CoS on an ATM Bundle
To configure IP to ATM CoS an ATM PVC bundle, perform the tasks in the following sections. The first four sections are required; the remaining sections are optional.
•
•
•
•
•
•
•
•
•
•
•
•
The IP to ATM CoS feature requires ATM PVC management and CEF switching functionality.
Creating a VC Bundle
To create a bundle and enter bundle configuration mode in which you can assign attributes and parameters to the bundle and all of its member VCs, use the following command in subinterface configuration mode:
bundle bundle-name
Creates the specified bundle and enters bundle configuration mode.
Applying Bundle-Level Parameters
Bundle-level parameters can be applied either by assigning VC classes or by directly applying them to the bundle.
Parameters applied through a VC class assigned to the bundle are superseded by those applied at the bundle level. Bundle-level parameters are superseded by parameters applied to an individual VC.
Configuring the Bundle-Level Parameters
Configuring the bundle-level parameters is optional if a class is attached to the bundle to configure it.
To configure parameters that apply to the bundle and all of its members, use the following commands in bundle configuration mode:
Configuring VC Class Parameters to Apply to a Bundle
Use of a VC class allows you to configure a bundle applying multiple attributes to it at once because you apply the class itself to the bundle. Use of a class allows you to generalize a parameter across all VCs, after which (for some parameters) you can modify that parameter for individual VCs. (See the section "Applying Parameters to Individual VCs" for more information.)
To configure a VC class to contain commands that configure all VC members of a bundle when the class is applied to that bundle, use the following command in vc-class configuration mode. To enter vc-class configuration mode, use the vc-class atm command.
oam-bundle [manage] [frequency]
Enables end-to-end F5 OAM loopback cell generation and OAM management for all VCs in the bundle.
In addition to these commands, you can add the following commands to a VC class to be used to configure a bundle: broadcast, encapsulation, inarp, oam, and protocol commands. For information on these commands, including configuration tasks and command syntax, refer to the Cisco IOS Wide-Area Networking Configuration Guide and the Cisco IOS Wide-Area Networking Command Reference.
Attaching a Class to a Bundle
To attach a preconfigured VC class containing bundle-level configuration commands to a bundle, use the following command in bundle configuration mode:
class vc-class-name
Configures a bundle with the bundle-level commands contained in the specified VC class.
Parameters set through bundle-level commands contained in the VC class are applied to the bundle and all of its VC members. Bundle-level parameters applied through commands configured directly on the bundle supersede those applied through a VC class.
Note that some bundle-level parameters applied through a VC class or directly to the bundle can be superseded by commands that you directly apply to individual VCs in bundle-vc configuration mode.
Committing a VC to a Bundle
To add a VC to an existing bundle and enter bundle-vc configuration mode, use the following command in bundle configuration mode:
pvc-bundle pvc-name [vpi/] [vci]
Adds the specified VC to the bundle and enters bundle-vc configuration mode in order to configure the specified VC bundle member.
For information on how to first create the bundle and configure it, see the sections "Creating a VC Bundle" and "Configuring VC Class Parameters to Apply to a Bundle" earlier in this feature module.
Applying Parameters to Individual VCs
Parameters can be applied to individual VCs either by using VC classes or by directly applying them to the bundle members.
Parameters applied to an individual VC supersede bundle-level parameters. Parameters applied directly to a VC take precedence over the same parameters applied within a class to the VC at the bundle-vc configuration level.
Configuring a VC Bundle Member Directly
Configuring VC bundle members directly is optional if a VC class is attached to the bundle member.
To configure an individual VC bundle member directly, use the following command in bundle-vc configuration mode:
Parameters set directly for a VC at the bundle-vc configuration level take precedence over values for these parameters set for the VC at any other level, including application of a VC class at the bundle-vc configuration level.
Configuring VC Class Parameters to Apply to a VC Bundle Member
To configure a VC class to contain commands that configure a specific VC member of a bundle when the class is applied to it, use the following commands in VC-class configuration mode. To enter vc-class configuration mode, use the vc-class atm command in global configuration mode.
You can also add the following commands to a VC class to be used to configure a VC bundle member: ubr+ and vbr-nrt.
Use of a VC class allows you to configure a VC bundle member with multiple attributes at once because you can apply the class to the VC.
Note
Applying a VC Class to a Discrete VC Bundle Member
To attach a preconfigured VC class containing bundle-level configuration commands to a bundle, use the following command in bundle configuration mode:
Parameters that configure a VC that are contained in a VC class assigned to that VC are superseded by parameters that are directly configured for the VC through discrete commands entered in bundle-vc configuration mode.
Configuring a VC Not to Accept Bumped Traffic
To configure an individual VC bundle member not to accept traffic that otherwise might be directed to it if the original VC carrying the traffic goes down, use the following command in bundle-vc configuration mode:
no bump traffic
Configures the VC not to accept any bumped traffic that would otherwise be redirected to it.
Monitoring and Maintaining VC Bundles and Their VC Members
To gather information on bundles so as to monitor them or to troubleshoot problems that pertain to their configuration or use, use one or more of the following commands in privileged EXEC mode or debug mode:
Configuration Examples
This section provides the following configuration examples:
•
•
Single ATM VC with WRED Group and IP Precedence Example
The following example creates a PVC on an ATM interface and applies the WRED parameter group sanjose to that PVC. Next, the IP Precedence values are configured for the WRED parameter group sanjose.
interface ATM1/1/0.46 multipointip address 200.126.186.2 255.255.255.0no ip mroute-cacheshutdownpvc cisco 46encapsulation aal5nlpidrandom-detect attach sanjose!random-detect-group sanjoseprecedence 0 200 1000 10precedence 1 300 1000 10precedence 2 400 1000 10precedence 3 500 1000 10precedence 4 600 1000 10precedence 5 700 1000 10precedence 6 800 1000 10precedence 7 900 1000 10!
VC Bundle Configuration Using a VC Class Example
This example configures VC bundle management on a router that uses Intermediate System-to-Intermediate System (IS-IS) as its IP routing protocol.
Bundle-Class Class
At the outset, this configuration defines a VC class called bundle-class that includes commands that set VC parameters. When the class bundle-class is applied at the bundle level, these parameters are applied to all VCs that belong to the bundle. Note that any commands applied directly to an individual VC of a bundle in bundle-vc mode take precedence over commands applied globally at the bundle level. Taking into account hierarchy precedence rules, VCs belonging to any bundle to which the class bundle-class is applied will be characterized by these parameters: aal5snap encapsulation, broadcast on, use of Inverse ARP to resolve IP addresses, and OAM enabled.
router isis net 49.0000.0000.0000.1111.00vc-class atm bundle-class encapsulation aal5snap broadcast protocol ip inarp oam-bundle manage 3 oam 4 3 10Control-Class Class
The following sections of the configuration define VC classes that contain commands specifying parameters that can be applied to individual VCs in a bundle by assigning the class to that VC.
When the class control-class is applied to a VC, the VC carries traffic whose IP Precedence level is 7. When the VC to which this class is assigned goes down, it takes the bundle down with it because this class makes the VC a protected one. The QoS type of a VC using this class is vbr-nrt.
vc-class atm control-class precedence 7 protect vc vbr-nrt 1000 5000 32Premium-Class Class
When the class premium-class is applied to a VC, the VC carries traffic whose IP Precedence level is 6 and 5. The VC does not allow other traffic to be bumped onto it. When the VC to which this class is applied goes down, its bumped traffic will be redirected to a VC whose IP Precedence level is 7. This class makes a VC a member of the protected group of the bundle. When all members of a protected group go down, the bundle goes down. The QoS type of a VC using this class is vbr-nrt.
vc-class atm premium-class precedence 6-5 no bump traffic protect groupbump explicitly 7 vbr-nrt 20000 10000 32Priority-Class Class
When the class priority-class is applied to a VC, the VC is configured to carry traffic with IP Precedence in the 4-2 range. The VC uses the implicit bumping rule, it allows traffic to be bumped, and it belongs to the bundle's protected group. The QoS type of a VC using this class is ubr+.
vc-class atm priority-class precedence 4-2 protect group ubr+ 10000 3000Basic-Class Class
When the class basic-class is applied to a VC, the VC is configured through the precedence other command to carry traffic with IP Precedence levels not specified in the profile. The VC using this class belongs to the bundle's protected group. The QoS type of a VC using this class is ubr.
vc-class atm basic-class precedence other protect group ubr 10000The following sets of commands configure three bundles that the router subinterface uses to connect to three of its neighbors. These bundles are called new-york, san-francisco, and los-angeles. Bundle new-york has four VC members, bundle san-francisco has four VC members, and bundle los-angeles has three VC members.
New-York Bundle
The first part of this example specifies the IP address of the subinterface, the router protocol—the router uses IS-IS as an IP routing protocol, and it creates the first bundle called new-york and enters bundle configuration mode.
int a1/0.1 multipoint ip address 10.0.0.1 255.255.255.0 ip router isis bundle new-yorkFrom within bundle configuration mode, the next portion of the configuration uses two protocol commands to enable IP and Open Systems Interconnect (OSI) traffic flows in the bundle. The OSI routing packets will use the highest precedence VC in the bundle. The OSI data packets, if any, will use the lowest precedence VC in the bundle. If configured, other protocols, such as IPX or AppleTalk, will always use the lowest precedence VC in the bundle.
As the indentation levels of the preceding and following commands suggest, subordinate to bundle new-york is a command that configures its protocol and a command that applies the class bundle-class to it.
protocol ip 1.1.1.2 broadcast protocol clns 49.0000.0000.2222.00 broadcastclass bundle-classThe class called bundle-class, which is applied to the bundle new-york, includes a protocol ip inarp command. According to inheritance rules, protocol ip, configured at the bundle level, takes precedence over protocol ip inarp specified in the class bundle-class.
The next set of commands beginning with pvc-bundle ny-control 207, which are further subordinate, add four VCs (named ny-control, ny-premium, ny-priority, and ny-basic) to the bundle new-york. A particular class—that is, one of the classes predefined in this configuration example—is applied to each VC to configure it with parameters specified by commands included in the class.
As is the case for this configuration, to configure individual VCs belonging to a bundle, the router must be in bundle mode for the mother bundle. For each VC belonging to the bundle, the subordinate mode is pvc-mode for the specific VC.
The following commands configure the individual VCs for the bundle new-york.
pvc-bundle ny-control 207 class control-class pvc-bundle ny-premium 206 class premium-class pvc-bundle ny-priority 204 class priority-class pvc-bundle ny-basic 201 class basic-classSan-Francisco Bundle
The following set of commands create and configure a bundle called san-francisco. At the bundle configuration level, the configuration commands included in the class bundle-class are ascribed to the bundle san-francisco and to the individual VCs that belong to the bundle. Then, the pvc-bundle command is executed for each individual VC to add it to the bundle. After a VC is added and bundle-vc configuration mode is entered, a particular, preconfigured class is assigned to the VC. The configuration commands comprising that class are used to configure the VC. Rules of hierarchy apply at this point. Command parameters contained in the applied class are superseded by same parameters applied at the bundle configuration level, which are superseded by same parameters applied directly to a VC.
bundle san-francisco protocol clns 49.0000.0000.0000.333.00 broadcast inarp 1 class bundle-class pvc-bundle sf-control 307 class control-class pvc-bundle sf-premium 306 class premium-class pvc-bundle sf-priority 304 class priority-class pvc-bundle sf-basic 301 class basic-classLos-Angeles Bundle
The following set of commands create and configure a bundle called los-angeles. At the bundle configuration level, the configuration commands included in the class bundle-class are ascribed to the bundle los-angeles and to the individual VCs that belong to the bundle. Then, the pvc-bundle command is executed for each individual VC to add it to the bundle. After a VC is added and bundle-vc configuration mode is entered, precedence is set for the VC and the VC is either configured as a member of a protected group (protect group) or as an individually protected VC. A particular class is then assigned to each VC to further characterize it. Rules of hierarchy apply. Parameters of commands applied directly and discretely to a VC take precedence over the same parameters applied within a class to the VC at the bundle-vc configuration level, which take precedence over the same parameters applied to the entire bundle at the bundle configuration level.
bundle los-angeles protocol ip 1.1.1.4 broadcast protocol clns 49.0000.0000.4444.00 broadcastinarp 1 class bundle-classpvc-bundle la-high 407 precedence 7-5 protect vc class premium-class pvc-bundle la-mid 404 precedence 4-2 protect group class priority-class pvc-bundle la-low 401 precedence other protect group class basic-classCommand Reference
This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.1 command reference publications.
•
•
•
•
•
atm pvc
To create a permanent virtual circuit (PVC) on an ATM interface and, optionally, to generate Operation, Administration, and Maintenance (OAM) F5 loopback cells or enable Inverse ATM ARP, use the atm pvc interface configuration command. To apply a WRED parameter group to the created PVC, specify the random-detect keyword and group-name argument. The no form of this command removes the specified PVC.
Note
atm pvc vcd vpi vci aal-encap [[midlow midhigh] [peak average [burst]]] [inarp [minutes]]
[oam [seconds] [random-detect [group-name]]
no atm pvc vcd vpi vci aal-encap [[midlow midhigh] [peak average [burst]]] [inarp [minutes]]
[oam [seconds][random-detect [group-name]]Syntax Description
Defaults
If peak and average rate values are omitted, the PVC defaults to peak and average rates equal to the link rate. The peak and average rates are then equal. By default, the virtual circuit is configured to run as fast as possible.
The default of both the midlow and midhigh values is 0.
If the oam keyword is omitted, OAM cells are not generated. If the oam keyword is present but the seconds value is omitted, the default value of oam seconds is 10 seconds.
If the inarp keyword is omitted, inverse ARPs are not generated. If the inarp keyword is present, but the timeout value is not given, then inverse ARPs are generated every 15 minutes.
When the random-detect keyword is used, if the group-name argument is omitted or no name match is found in the current configuration for the specified group-name, a set of default WRED parameters are applied to the PVC.
If the random-detect keyword is omitted, WRED is turned off for the PVC.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0. The midlow and midhigh arguments first appeared in Cisco IOS Release 10.3.
This command is used for single VCs, not VC bundles. However, the atm pvc command will be obsoleted in the near future, so we discourage use of it. See the note
