- Index
- Preface
- Using Cisco IOS Software
- SIP, SSC, and SPA Product Overview
-
- Overview of the IPsec VPN SPA
- Configuring VPNs in Crypto-Connect Mode
- Configuring VPNs in VRF Mode
- Configuring IPsec VPN Fragmentation and MTU
- Configuring IKE Features Using the IPsec VPN SPA
- Configuring Enhanced IPsec Features Using the IPsec VPN SPA
- Configuring PKI Using the IPsec VPN SPA
- Configuring Advanced VPNs Using the IPsec VPN SPA
- Configuring Duplicate Hardware and IPsec Failover Using the IPsec VPN SPA
- Configuring Monitoring and Accounting for the IPsec VPN SPA
- Troubleshooting the IPsec VPN SPA
- Glossary
- Configuration Tasks
- Required Configuration Tasks
- Specifying the Interface Address on a SPA
- Modifying the Interface MTU Size
- Creating a Permanent Virtual Circuit
- Creating a PVC on a Point-to-Point Subinterface
- Configuring a PVC on a Multipoint Subinterface
- Configuring RFC 1483 Bridging for PVCs
- Layer 2 Protocol Tunneling Topology CLI Configuration Task
- Configuring RFC 1483 Bridging for PVCs with IEEE 802.1Q Tunneling
- Configuring ATM RFC 1483 Half-Bridging
- Configuring ATM Routed Bridge Encapsulation
- Configuring RFC 1483 Bridging of Routed Encapsulations
- Configuring MPLS over RBE
- Configuring Aggregate WRED for PVCs
- Creating and Configuring Switched Virtual Circuits
- Configuring Traffic Parameters for PVCs or SVCs
- Configuring Virtual Circuit Classes
- Configuring Virtual Circuit Bundles
- Configuring Multi-VLAN to VC Support
- Configuring Link Fragmentation and Interleaving with Virtual Templates
- Configuring the Distributed Compressed Real-Time Protocol
- Configuring Automatic Protection Switching
- Configuring SONET and SDH Framing
- Configuring for Transmit-Only Mode
- Saving the Configuration
- Shutting Down and Restarting an Interface on a SPA
- Shutting Down an ATM Shared Port Adapter
- Verifying the Interface Configuration
- Configuration Examples
- Basic Interface Configuration Example
- MTU Configuration Example
- Permanent Virtual Circuit Configuration Example
- PVC on a Point-to-Point Subinterface Configuration Example
- PVC on a Multipoint Subinterface Configuration Example
- RFC 1483 Bridging for PVCs Configuration Example
- RFC 1483 Bridging for PVCs with IEEE 802.1Q Tunneling Configuration Example
- ATM RFC 1483 Half-Bridging Configuration Example
- ATM Routed Bridge Encapsulation Configuration Example
- Precedence-Based Aggregate WRED Configuration Example
- DSCP-Based Aggregate WRED Configuration Example
- Switched Virtual Circuits Configuration Example
- Traffic Parameters for PVCs or SVCs Configuration Example
- Virtual Circuit Classes Configuration Example
- Virtual Circuit Bundles Configuration Example
- Link Fragmentation and Interleaving with Virtual Templates Configuration Example
- Distributed Compressed Real-Time Protocol Configuration Example
- Automatic Protection Switching Configuration Example
- SONET and SDH Framing Configuration Example
- Layer 2 Protocol Tunneling Topology with a Cisco 7600, Catalyst 5500, and Catalyst 6500 Configuration Example
- Layer 2 Protocol Tunneling Topology with a Cisco 7600 and Cisco 7200 Configuration Example
- Cisco 7600 Basic Back-to-Back Configuration Example
- Catalyst 5500 Switch and Cisco 7600 Series Routers in Back-to-Back Topology Configuration Example
- Cisco 7600 and Cisco 7200 in Back-to-Back Topology Configuration Example
Configuring the ATM SPAs
This chapter provides information about configuring the ATM SPAs on the Catalyst 6500 Series switch. It includes the following sections:
•Verifying the Interface Configuration
For information about managing your system images and configuration files, refer to the Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.2 and Cisco IOS Configuration Fundamentals Command Reference, Release 12.2 publications.
For more information about the commands used in this chapter, see the Catalyst 6500 Series Cisco IOS Command Reference, 12.2SX publication. Also refer to the related Cisco IOS Release 12.2 software command reference and master index publications. For more information about accessing these publications, see the "Related Documentation" section.
Configuration Tasks
This section describes the most common configurations for the ATM SPAs on a Catalyst 6500 Series switch. It contains procedures for the following configurations:
•Specifying the Interface Address on a SPA
•Modifying the Interface MTU Size
•Creating a Permanent Virtual Circuit
•Creating a PVC on a Point-to-Point Subinterface
•Configuring a PVC on a Multipoint Subinterface
•Configuring RFC 1483 Bridging for PVCs
•Configuring RFC 1483 Bridging for PVCs with IEEE 802.1Q Tunneling
•Configuring ATM RFC 1483 Half-Bridging
•Configuring ATM Routed Bridge Encapsulation
•Configuring RFC 1483 Bridging of Routed Encapsulations
•Configuring Aggregate WRED for PVCs
•Creating and Configuring Switched Virtual Circuits
•Configuring Traffic Parameters for PVCs or SVCs
•Configuring Virtual Circuit Classes
•Configuring Virtual Circuit Bundles
•Configuring Multi-VLAN to VC Support
•Configuring Link Fragmentation and Interleaving with Virtual Templates
•Configuring the Distributed Compressed Real-Time Protocol
•Configuring Automatic Protection Switching
•Configuring SONET and SDH Framing
•Configuring for Transmit-Only Mode
•Shutting Down and Restarting an Interface on a SPA
•Shutting Down an ATM Shared Port Adapter
Required Configuration Tasks
The ATM SPA interface must be initially configured with an IP address to allow further configuration. Some of the required configuration commands implement default values that might or might not be appropriate for your network. If the default value is correct for your network, then you do not need to configure the command. To perform the basic configuration of each interface, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# interface atm slot/subslot/port |
Enters interface configuration mode for the indicated port on the specified ATM SPA. |
Step 2 |
Router(config-if)# ip address address mask [secondary] |
(Optional in some configurations) Assigns the specified IP address and subnet mask to the interface. Repeat the command with the optional secondary keyword to assign additional, secondary IP addresses to the port. |
Step 3 |
Router(config-if)# description string |
(Optional) Assigns an arbitrary string, up to 80 characters long, to the interface. This string can identify the purpose or owner of the interface, or any other information that might be useful for monitoring and troubleshooting. |
Step 4 |
Router(config-if)# no shutdown |
Enables the interface. |
Repeat Step 1 through Step 4 for each port on the ATM SPA to be configured. |
||
Step 5 |
Router(config-if)# end |
Exits interface configuration mode and returns to privileged EXEC mode. |
Specifying the Interface Address on a SPA
Two ATM SPAs can be installed in a SIP. SPA interface ports begin numbering with "0" from left to right. Single-port SPAs use only the port number 0. To configure or monitor SPA interfaces, you need to specify the physical location of the SIP, SPA, and interface in the CLI. The interface address format is slot/subslot/port, where:
•slot—Specifies the chassis slot number in the Catalyst 6500 Series switch where the SIP is installed.
•subslot—Specifies the secondary slot of the SIP where the SPA is installed.
•port—Specifies the number of the individual interface port on a SPA.
The following example shows how to specify the first interface (0) on a SPA installed in the first subslot of a SIP (0) installed in chassis slot 3:
Router(config)# interface serial 3/0/0
This command shows a serial SPA as a representative example, however the same slot/subslot/port format is similarly used for other SPAs (such as ATM and POS) and other non-channelized SPAs.
For more information about identifying slots and subslots, see the "Identifying Slots and Subslots for SIPs, SSCs, and SPAs" section.
Modifying the Interface MTU Size
The maximum transmission unit (MTU) values might need to be reconfigured from their defaults on the ATM SPAs to match the values used in your network.
Interface MTU Configuration Guidelines
When configuring the interface MTU size on an ATM SPA, consider the following guidelines.
The Cisco IOS software supports several types of configurable MTU options at different levels of the protocol stack. You should ensure that all MTU values are consistent to avoid unnecessary fragmentation of packets. These MTU values are the following:
•Interface MTU—Configured on a per-interface basis and defines the maximum packet size (in bytes) that is allowed for traffic received on the network. The ATM SPA checks traffic coming in from the network and drops packets that are larger than this maximum value. Because different types of Layer 2 interfaces support different MTU values, choose a value that supports the maximum possible packet size that is possible in your particular network topology.
•IP MTU—Configured on a per-interface or per-subinterface basis and determines the largest maximum IP packet size (in bytes) that is allowed on the IP network without being fragmented. If an IP packet is larger than the IP MTU value, the ATM SPA fragments it into smaller IP packets before forwarding it on to the next hop.
•Multiprotocol Label Switching (MPLS) MTU—Configured on a per-interface or per-subinterface basis and defines the MTU value for packets that are tagged with MPLS labels or tag headers. When an IP packet that contains MPLS labels is larger than the MPLS MTU value, the ATM SPA fragments it into smaller IP packets. When a non-IP packet that contains MPLS labels is larger than the MPLS MTU value, the ATM SPA drops it.
All devices on a particular physical medium must have the same MPLS MTU value to allow proper MPLS operation. Because MPLS labels are added on to the existing packet and increase the packet's size, choose appropriate MTU values so as to avoid unnecessarily fragmenting MPLS-labeled packets.
If the IP MTU or MPLS MTU values are currently the same size as the interface MTU, changing the interface MTU size also automatically sets the IP MTU or MPLS MTU values to the new value. Changing the interface MTU value does not affect the IP MTU or MPLS MTU values if they are not currently set to the same size as the interface MTU.
Different encapsulation methods and the number of MPLS MTU labels add additional overhead to a packet. For example, SNAP encapsulation adds an 8-byte header, IEEE 802.1Q encapsulation adds a 2-byte header, and each MPLS label adds a 4-byte header. Consider the maximum possible encapsulations and labels that are to be used in your network when choosing the MTU values.
Tip The MTU values on the local ATM SPA interfaces must match the values being used in the ATM network and remote ATM interface. Changing the MTU values on an ATM SPA does not reset the local interface, but be aware that other platforms and ATM SPAs do reset the link when the MTU value changes. This could cause a momentary interruption in service, so we recommend changing the MTU value only when the interface is not being used.
Note The interface MTU value on the ATM SPA also determines which packets are recorded as "giants" in the show interfaces atm command. The interface considers a packet to be a giant packet when it is more than 24 bytes larger than the interface MTU size. For example, if using an MTU size of 1500 bytes, the interface increments the giants counter when it receives a packet larger than 1524 bytes.
Interface MTU Configuration Task
To change the MTU values on the ATM SPA interfaces, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# interface atm slot/subslot/port |
Enters interface configuration mode for the indicated port on the specified ATM SPA. |
Step 2 |
Router(config-if)# mtu bytes |
(Optional) Configure the maximum transmission unit (MTU) size for the interface. The valid range for bytes is from 64 to 9216 bytes, with a default of 4470 bytes. As a general rule, do not change the MTU value unless you have a specific application need to do so. Note If the IP MTU or MPLS MTU values are currently the same size as the interface MTU, changing the interface MTU size also automatically sets the IP MTU or MPLS MTU values to the same value. |
Step 3 |
Router(config-if)# ip mtu bytes |
(Optional) Configures the MTU value, in bytes, for IP packets on this interface. The valid range for an ATM SPA is 64 to 9288, with a default value equal to the MTU value configured in Step 2. |
Step 4 |
Router(config-if)# mpls mtu bytes |
(Optional) Configures the MTU value, in bytes, for MPLS-labeled packets on this interface. The valid range for an ATM SPA is 64 to 9216 bytes, with a default value equal to the MTU value configured in Step 2. |
Note Repeat Step 1 through Step 4 for each interface port on the ATM SPA to be configured. |
||
Step 5 |
Router(config-if)# end |
Exits interface configuration mode and returns to privileged EXEC mode. |
Verifying the MTU Size
To verify the MTU sizes for an interface, use the show interface, show ip interface, and show mpls interface commands, as in the following example:
Router# show interface atm 4/1/0
ATM4/1/0 is up, line protocol is up
Hardware is SPA-4XOC3-ATM, address is 000d.2959.d5ca (bia 000d.2959.d5ca)
MTU 4470 bytes, sub MTU 4470, BW 149760 Kbit, DLY 80 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ATM, loopback not set
Encapsulation(s): AAL5
4095 maximum active VCs, 0 current VCCs
VC idle disconnect time: 300 seconds
0 carrier transitions
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Router# show ip interface atm 4/1/0
ATM4/1/0 is up, line protocol is up
Internet address is 200.1.0.2/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 4470 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.9
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP Flow switching is disabled
IP Feature Fast switching turbo vector
IP Null turbo vector
VPN Routing/Forwarding "vpn2600-2"
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, CEF
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Probe proxy name replies are disabled
Policy routing is disabled
Network address translation is disabled
WCCP Redirect outbound is disabled
WCCP Redirect exclude is disabled
BGP Policy Mapping is disabled
Router# show mpls interface atm 4/1/0 detail
Interface ATM3/0:
IP labeling enabled (ldp)
LSP Tunnel labeling not enabled
MPLS operational
MPLS turbo vector
MTU = 4470
ATM labels: Label VPI = 1
Label VCI range = 33 - 65535
Control VC = 0/32
To view the maximum possible size for datagrams passing out the interface using the configured MTU value, use the show atm interface atm command:
Router# show atm interface atm 4/1/0
Interface ATM4/1/0:
AAL enabled: AAL5, Maximum VCs: 4096, Current VCCs: 2
Maximum Transmit Channels: 0
Max. Datagram Size: 4528
PLIM Type: SONET - 155000Kbps, TX clocking: LINE
Cell-payload scrambling: ON
sts-stream scrambling: ON
8359 input, 8495 output, 0 IN fast, 0 OUT fast, 0 out drop
Avail bw = 155000
Config. is ACTIVE
Creating a Permanent Virtual Circuit
To use a permanent virtual circuit (PVC), configure the PVC in both the switch and the ATM switch. PVCs remain active until the circuit is removed from either configuration. To create a PVC on the ATM interface and enter interface ATM VC configuration mode, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# interface atm slot/subslot/port or Router(config)# interface atm slot/subslot/port.subinterface |
Enters interface or subinterface configuration mode for the indicated port on the specified ATM SPA. |
Step 2 |
Router(config-if)# ip address address mask |
Assigns the specified IP address and subnet mask to the interface or subinterface. |
Step 3 |
Router(config-if)# atm tx-latency milliseconds |
(Optional) Configures the default transmit latency for VCs on this ATM SPA interface. The valid range for milliseconds is from 1 to 200, with a default of 100 milliseconds. |
Step 4 |
Router(config-if)# pvc [name] vpi/vci [ilmi | qsaal] |
Configures a new ATM PVC by assigning its VPI/VCI numbers and enters ATM VC configuration mode. The valid values for vpi/vci are: vpi—Specifies the VPI ID. The valid range is 0 to 255. vci—Specifies the VCI ID. The valid range is 1 to 65535. Values 1 to 31 are reserved and should not be used, except for 5 for the QSAAL PVC and 16 for the ILMI PVC. You can also configure the following options: name—(Optional) An arbitrary string that identifies this PVC. ilmi—(Optional) Configures the VC to exclusively carry ILMI protocol traffic (default). qsaal—(Optional) Configures the VC to exclusively carry qsaal protocol traffic. |
Note When using the pvc command, remember that the vpi/vci combination forms a unique identifier for the interface and all of its subinterfaces. If you specify a vpi/vci combination that has been used on another subinterface, the Cisco IOS software assumes that you want to modify that PVC's configuration and automatically switches to its parent subinterface. |
||
Step 5 |
Router(config-if-atm-vc)# protocol protocol {protocol-address | inarp} [[no] broadcast] |
Configures the PVC for a particular protocol and maps it to a specific protocol-address. protocol—Typically set to either ip or ppp, but other values are possible. protocol-address—Destination address or virtual interface template for this PVC (if appropriate for the protocol). inarp—Specifies that the PVC uses Inverse ARP to determine its address. [no] broadcast—(Optional) Specifies that this mapping should (or should not) be used for broadcast packets. |
Step 6 |
Router(config-if-atm-vc)# inarp minutes |
(Optional) If using Inverse ARP, configures how often the PVC transmits Inverse ARP requests to confirm its address mapping. The valid range is 1 to 60 minutes, with a default of 15 minutes. |
Step 7 |
Router(config-if-atm-vc)# encapsulation aal5snap |
(Optional) Configures the ATM adaptation layer (AAL) and encapsulation type. The default and only supported type is aal5snap. |
Step 8 |
Router(config-if-atm-vc)# tx-limit buffers |
(Optional) Specifies the number of transmit buffers for this VC. The valid range is from 1 to 57343, with a default value that is based on the current VC line rate and on the latency value that is configured with the atm tx-latency command. |
Note Repeat Step 4 through Step 8 for each PVC to be configured on this interface. |
||
Step 9 |
Router(config-if-atm-vc)# end |
Exits ATM VC configuration mode and returns to privileged EXEC mode. |
Verifying a PVC Configuration
To verify the configuration of a particular PVC, use the show atm pvc command:
Router# show atm pvc 1/100
ATM3/0/0: VCD: 1, VPI: 1, VCI: 100
UBR, PeakRate: 149760
AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0
OAM frequency: 0 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Disabled
OAM VC status: Not Managed
ILMI VC status: Not Managed
InARP frequency: 15 minutes(s)
Transmit priority 6
InPkts: 94964567, OutPkts: 95069747, InBytes: 833119350, OutBytes: 838799016
InPRoc: 1, OutPRoc: 1, Broadcasts: 0
InFast: 0, OutFast: 0, InAS: 94964566, OutAS: 95069746
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0, LengthViolation: 0, CPIErrors: 0
Out CLP=1 Pkts: 0
OAM cells received: 0
F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0
F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0
OAM cells sent: 0
F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutRDI: 0
F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0
OAM cell drops: 0
Status: UP
VC 1/100 doesn't exist on 7 of 8 ATM interface(s)
Tip To verify the configuration and current status of all PVCs on a particular interface, you can also use the show atm vc interface atm command.
Creating a PVC on a Point-to-Point Subinterface
Use point-to-point subinterfaces to provide each pair of switches with its own subnet. When you create a PVC on a point-to-point subinterface, the switch assumes it is the only point-to-point PVC that is configured on the subinterface, and it forwards all IP packets with a destination IP address in the same subnet to this VC. To configure a point-to-point PVC, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# interface atm slot/subslot/port.subinterface point-to-point |
Creates the specified point-to-point subinterface on the given port on the specified ATM SPA, and enters subinterface configuration mode. |
Step 2 |
Router(config-subif)# ip address address mask |
Assigns the specified IP address and subnet mask to this subinterface. |
Step 3 |
Router(config-subif)# pvc [name] vpi/vci [ilmi | qsaal] |
Configures a new ATM PVC by assigning its VPI/VCI numbers and enters ATM VC configuration mode. The valid values for vpi/vci are: vpi—Specifies the VPI ID. The valid range is 0 to 255. vci—Specifies the VCI ID. The valid range is 1 to 65535. Values 1 to 31 are reserved and should not be used, except for 5 for the QSAAL PVC and 16 for the ILMI PVC. You can also configure the following options: name—(Optional) An arbitrary string that identifies this PVC. ilmi—(Optional) Configures the PVC to use ILMI encapsulation (default). qsaal—(Optional) Configures the PVC to use QSAAL encapsulation. |
Note When using the pvc command, remember that the vpi/vci combination forms a unique identifier for the interface and all of its subinterfaces. If you specify a vpi/vci combination that has been used on another subinterface, the Cisco IOS software assumes that you want to modify that PVC's configuration and automatically switches to its parent subinterface. |
||
Step 4 |
Router(config-if-atm-vc)# protocol protocol protocol-address [[no] broadcast] |
Configures the PVC for a particular protocol and maps it to a specific protocol-address. protocol—Typically set to ppp for point-to-point subinterfaces, but other values are possible. protocol-address—Destination address or virtual template interface for this PVC (as appropriate for the specified protocol). [no] broadcast—(Optional) Specifies that this mapping should (or should not) be used for broadcast packets. The protocol command also has an inarp option, but this option is not meaningful on point-to-point PVCs that use a manually configured address. |
Step 5 |
Router(config-if-atm-vc)# encapsulation aal5snap |
(Optional) Configures the ATM adaptation layer (AAL) and encapsulation type. The default and only supported type is aal5snap. |
Repeat Step 1 through Step 5 for each point-to-point subinterface to be configured on this ATM SPA. |
||
Step 6 |
Router(config-if)# end |
Exits interface configuration mode and returns to privileged EXEC mode. |
Verifying a Point-to-Point PVC Configuration
To verify the configuration of a particular PVC, use the show atm pvc command:
Router# show atm pvc 3/12
ATM3/1/0.12: VCD: 3, VPI: 3, VCI: 12
UBR, PeakRate: 149760
AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0
OAM frequency: 0 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Disabled
OAM VC status: Not Managed
ILMI VC status: Not Managed
InARP frequency: 15 minutes(s)
Transmit priority 6
InPkts: 3949645, OutPkts: 3950697, InBytes: 28331193, OutBytes: 28387990
InPRoc: 1, OutPRoc: 1, Broadcasts: 0
InFast: 0, OutFast: 0, InAS: 3949645, OutAS: 3950697
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0, LengthViolation: 0, CPIErrors: 0
Out CLP=1 Pkts: 0
OAM cells received: 0
F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0
F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0
OAM cells sent: 0
F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutRDI: 0
F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0
OAM cell drops: 0
Status: UP
Tip To verify the configuration and current status of all PVCs on a particular interface, you can also use the show atm vc interface atm command.
Configuring a PVC on a Multipoint Subinterface
Creating a multipoint subinterface allows you to create a point-to-multipoint PVC that can be used as a broadcast PVC for all multicast requests. To create a PVC on a multipoint subinterface, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# interface atm slot/subslot/port.subinterface multipoint |
Creates the specified point-to-multipoint subinterface on the given port on the specified ATM SPA, and enters subinterface configuration mode. |
Step 2 |
Router(config-subif)# ip address address mask |
Assigns the specified IP address and subnet mask to this subinterface. |
Step 3 |
Router(config-subif)# no ip directed-broadcast |
(Optional) Disables the forwarding of IP directed broadcasts, which are sometimes used in denial of service (DOS) attacks. |
Step 4 |
Router(config-subif)# pvc [name] vpi/vci [ilmi | qsaal] |
Configures a new ATM PVC by assigning its VPI/VCI numbers and enters ATM VC configuration mode. The valid values for vpi/vci are: •vpi—Specifies the VPI ID. The valid range is 0 to 255. •vci—Specifies the VCI ID. The valid range is 1 to 65535. Values 1 to 31 are reserved and should not be used, except for 5 for the QSAAL PVC and 16 for the ILMI PVC. You can also configure the following options: •name—(Optional) An arbitrary string that identifies this PVC. •ilmi—(Optional) Configures the PVC to use ILMI encapsulation (default). •qsaal—(Optional) Configures the PVC to use QSAAL encapsulation. |
Note When using the pvc command, remember that the vpi/vci combination forms a unique identifier for the interface and all of its subinterfaces. If you specify a vpi/vci combination that has been used on another subinterface, the Cisco IOS software assumes that you want to modify that PVC's configuration and automatically switches to its parent subinterface. |
||
Step 5 |
Router(config-if-atm-vc)# protocol protocol {protocol-address | inarp} broadcast |
Configures the PVC for a particular protocol and maps it to a specific protocol-address. •protocol—Typically set to ip for multipoint subinterfaces, but other values are possible. •protocol-address—Destination address or virtual template interface for this PVC (if appropriate for the protocol). •inarp—Specifies that the PVC uses Inverse ARP to determine its address. •broadcast— Specifies that this mapping should be used for multicast packets. |
Step 6 |
Router(config-if-atm-vc)# inarp minutes |
(Optional) If using Inverse ARP, configures how often the PVC transmits Inverse ARP requests to confirm its address mapping. The valid range is 1 to 60 minutes, with a default of 15 minutes. |
Step 7 |
Router(config-if-atm-vc)# encapsulation aal5snap |
(Optional) Configures the ATM adaptation layer (AAL) and encapsulation type. The default and only supported type is aal5snap. |
Note Repeat Step 1 through Step 7 for each multipoint subinterface to be configured on this ATM SPA. |
||
Step 8 |
Router(config-if)# end |
Exits interface configuration mode and returns to privileged EXEC mode. |
Verifying a Multipoint PVC Configuration
To verify the configuration of a particular PVC, use the show atm pvc command:
Router# show atm pvc 1/120
ATM3/1/0.120: VCD: 1, VPI: 1, VCI: 120
UBR, PeakRate: 149760
AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0
OAM frequency: 0 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Disabled
OAM VC status: Not Managed
ILMI VC status: Not Managed
InARP frequency: 15 minutes(s)
Transmit priority 6
InPkts: 1394964, OutPkts: 1395069, InBytes: 1833119, OutBytes: 1838799
InPRoc: 1, OutPRoc: 1, Broadcasts: 0
InFast: 0, OutFast: 0, InAS: 94964, OutAS: 95062
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0, LengthViolation: 0, CPIErrors: 0
Out CLP=1 Pkts: 0
OAM cells received: 0
F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0
F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0
OAM cells sent: 0
F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutRDI: 0
F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0
OAM cell drops: 0
Status: UP
Note To verify the configuration and current status of all PVCs on a particular interface, you can also use the show atm vc interface atm command.
Configuring RFC 1483 Bridging for PVCs
RFC 1483, Multiprotocol Encapsulation over ATM Adaptation Layer 5, specifies the implementation of point-to-point bridging of Layer 2 PDUs from an ATM interface. Figure 7-1 shows an example in which the two routers receive VLANs over their respective trunk links and then forward that traffic out through the ATM interfaces into the ATM cloud. In this example, the device with the ATM SPA is shown as a router, but it can also be a Catalyst 6500 series switch.
Figure 7-1 Example of RFC 1483 Bridging Topology
Tip RFC 1483 has been updated and superseded by RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5.
RFC 1483 Bridging for PVCs Configuration Guidelines
When configuring RFC 1483 bridging for PVCs, consider the following guidelines:
•PVCs must use AAL5 Subnetwork Access Protocol (SNAP) encapsulation.
•To use the Virtual Trunking Protocol (VTP), ensure that each main interface has a subinterface that has been configured for the management VLANs (VLANs 1 and 1002-1005). VTP is not supported on bridged VCs on a Cisco 7600 SIP-200.
•RFC 1483 bridging in a switched virtual circuit (SVC) environment is not supported.
•The 1-Port OC-48c/STM-16 ATM SPA does not support RFC 1483 bridging.
RFC 1483 Bridging for PVCs Configuration Task
To configure RFC 1483 bridging for PVCs, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# interface atm slot/subslot/port.subinterface point-to-point |
(Optional) Creates the specified point-to-point subinterface on the given port on the specified ATM SPA card, and enters subinterface configuration mode. Note Although it is most common to create the PVCs on subinterfaces, you can also omit this step to create the PVCs for RFC 1483 bridging on the main interface. |
Step 2 |
Router(config-subif)# pvc [name] vpi/vci [ilmi | qsaal] |
Configures a new ATM PVC by assigning its VPI/VCI numbers and enters ATM VC configuration mode. The valid values for vpi/vci are: •vpi—Specifies the VPI ID. The valid range is 0 to 255. •vci—Specifies the VCI ID. The valid range is 1 to 65535. Values 1 to 31 are reserved and should not be used, except for 5 for the QSAAL PVC and 16 for the ILMI PVC. You can also configure the following options: •name—(Optional) An arbitrary string that identifies this PVC. •ilmi—(Optional) Configures the PVC to use ILMI encapsulation (default). •qsaal—(Optional) Configures the PVC to use QSAAL encapsulation. |
Step 3 |
Router(config-if-atm-vc)#bridge-domain vlan-id [access | dot1q | dot1q-tunnel] [ignore-bpdu-pid] | {pvst-tlv CE-vlan} [increment] [split-horizon]
|
Binds the PVC to the specified vlan-id. You can optionally specify the following keywords: •dot1q—(Optional) Includes the IEEE 802.1Q tag, which preserves the VLAN ID and class of service (CoS) information across the ATM cloud. •dot1q-tunnel—(Optional) Enables tunneling of IEEE 802.1Q VLANs over the same link. See the "Configuring RFC 1483 Bridging for PVCs with IEEE 802.1Q Tunneling" section. •ignore-bpdu-pid—(Optional) Ignores bridge protocol data unit (BPDU) packets, to allow interoperation with ATM customer premises equipment (CPE) devices that do not distinguish BPDU packets from data packets. Without this keyword, IEEE BPDUs are sent out using a PID of 0x00-0E, which complies with RFC 1483. With this keyword, IEEE BPDUs are sent out using a PID of 0x00-07, which is normally reserved for RFC 1483 data. •pvst-tlv—When transmitting, the pvst-tlv keyword translates PVST+ BPDUs into IEEE BPDUs. When receiving, the pvst-tlv keyword translates IEEE BPDUs into PVST+ BPDUs. •split-horizon—(Optional) Enables RFC 1483 split horizon mode to globally prevent bridging between PVCs in the same VLAN. |
Step 4 |
Router(config-if-atm-vc)# encapsulation aal5snap |
(Optional) Configures the ATM adaptation layer (AAL) and encapsulation type. The default and only supported type is aal5snap. |
Note Repeat Step 1 through Step 4 for each interface on the ATM SPA to be configured. |
||
Step 5 |
Router(config-if-atm-vc)# end |
Exits ATM VC configuration mode and returns to privileged EXEC mode. |
Verifying the RFC 1483 Bridging Configuration
To verify the RFC 1483 bridging configuration and status, use the show interface atm command:
Router# show interface atm 6/1/0.3
ATM6/1/0.3 is up, line protocol is up
Hardware is SPA-4XOC3-ATM
Internet address is 10.10.10.13/24
MTU 4470 bytes, BW 149760 Kbit, DLY 80 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ATM
5 packets input, 566 bytes
5 packets output, 566 bytes
1445 OAM cells input, 1446 OAM cells output
Layer 2 Protocol Tunneling Topology CLI Configuration Task
To enable BPDU translation for the Layer 2 Protocol Tunneling (L2PT) topologies, use the following command:
bridge-domain PE-vlan dot1q-tunnel ignore-bpdu-pid pvst-tlv CE-vlan
Configuring RFC 1483 Bridging for PVCs with IEEE 802.1Q Tunneling
RFC 1483 bridging (see the "Configuring RFC 1483 Bridging for PVCs" section) can also include IEEE 802.1Q tunneling, which 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 securing the customer networks.
Also, the IEEE 802.1Q tunneling is configured only on the service provider switches, so it does not require any additional configuration on the customer-side switches. The customer side is not aware of the configuration.
Note For complete information on IEEE 802.1Q tunneling on the Catalyst 6500 series switch, see the Catalyst 6500 Series Cisco IOS Software Configuration Guide, 12.2SX at the following URL:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/book.html
Note RFC 1483 has been updated and superseded by RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5.
RFC 1483 Bridging for PVCs with IEEE 802.1Q Tunneling Configuration Guidelines
When configuring RFC 1483 bridging for PVCs with IEEE 802.1Q tunneling, consider the following guidelines:
•Customer equipment must be configured for RFC 1483 bridging with IEEE 802.1Q tunneling, using the bridge-domain dot1q ATM VC configuration command. See the "Configuring RFC 1483 Bridging for PVCs" section for more information.
•PVCs must use AAL5 encapsulation.
•RFC 1483 bridged PVCs must terminate on the ATM SPA, and the traffic forwarded over this bridged connection to the edge must be forwarded through an Ethernet port.
•To use the Virtual Trunking Protocol (VTP), each main interface should have a subinterface that has been configured for the management VLANs (VLANs 1 and 1002-1005).
•RFC 1483 bridging in a switched virtual circuit (SVC) environment is not supported.
RFC 1483 Bridging for PVCs with IEEE 802.1Q Tunneling Configuration Task
To configure RFC 1483 bridging for PVCs with IEEE 802.1Q tunneling, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# interface atm slot/subslot.port.subinterface point-to-point |
(Optional) Creates the specified point-to-point subinterface on the given port on the specified ATM SPA, and enters subinterface configuration mode. Note Although it is most common to create the PVCs on subinterfaces, you can also omit this step to create the PVCs for RFC 1483 bridging on the main interface. |
Step 2 |
Router(config-subif)# pvc [name] vpi/vci [ilmi | qsaal] |
Configures a new ATM PVC by assigning its VPI/VCI numbers and enters ATM VC configuration mode. The valid values for vpi/vci are: •vpi—Specifies the VPI ID. The valid range is 0 to 255. •vci—Specifies the VCI ID. The valid range is 1 to 65535. Values 1 to 31 are reserved and should not be used, except for 5 for the QSAAL PVC and 16 for the ILMI PVC. You can also configure the following options: •name—(Optional) An arbitrary string that identifies this PVC. •ilmi—(Optional) Configures the PVC to use ILMI encapsulation (default). •qsaal—(Optional) Configures the PVC to use QSAAL encapsulation. |
Note When using the pvc command, remember that the vpi/vci combination forms a unique identifier for the interface and all of its subinterfaces. If you specify a vpi/vci combination that has been used on another subinterface, the Cisco IOS software assumes that you want to modify that PVC's configuration and automatically switches to its parent subinterface. |
||
Step 3 |
Router(config-if-atm-vc)# bridge-domain vlan-id dot1q-tunnel |
Binds the PVC to the specified vlan-id and enables the use of IEEE 802.1Q tunneling on the PVC. This preserves the VLAN ID information across the ATM cloud. |
Step 4 |
Router(config-if-atm-vc)# encapsulation aal5snap |
(Optional) Configures the ATM adaptation layer (AAL) and encapsulation type. The default and only supported type is aal5snap. |
Note Repeat Step 1 through Step 4 for each interface on the ATM SPA to be configured. |
||
Step 5 |
Router(config-if-atm-vc)# end |
Exits ATM VC configuration mode and returns to privileged EXEC mode. |
Verifying the RFC 1483 for PVCs Bridging with IEEE 802.1Q Tunneling Configuration
To verify the IEEE 802.1Q tunneling on an ATM SPA, use the show 12-protocol-tunnel command:
Router# show l2protocol-tunnel
COS for Encapsulated Packets: 5
Port Protocol Shutdown Drop Encapsulation Decapsulation Drop
Threshold Threshold Counter Counter Counter
------- -------- --------- --------- ------------- ------------- -------------
Gi4/2 cdp ---- ---- 0 0 0
stp ---- ---- 0 0 0
vtp ---- ---- 0 0 0
ATM6/2/1 cdp ---- ---- n/a n/a n/a
stp ---- ---- n/a n/a n/a
vtp ---- ---- n/a n/a n/a
Note The counters in the output of the show l2protocol-tunnel command are not applicable for ATM interfaces when IEEE 802.1Q tunneling is enabled.
Use the following command to display the interfaces that are configured with an IEEE 802.1Q tunnel:
Router# show dot1q-tunnel
LAN Port(s)
-----------
Gi4/2
ATM Port(s)
-----------
ATM6/2/1
Configuring ATM RFC 1483 Half-Bridging
The ATM SPA supports ATM RFC 1483 half-bridging, which routes IP traffic from a stub-bridged ATM LAN over bridged RFC 1483 Ethernet traffic, 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.
For example, Figure 7-2 shows a remote bridged Ethernet network connecting to a routed network over a device that bridges the Ethernet LAN to the ATM interface.
Figure 7-2 ATM RFC 1483 Half-Bridging
When half-bridging is configured, the ATM interface receives the bridged IP packets and routes them according to each packet's IP destination address. Similarly, when packets are routed to this ATM PVC, it then forwards them out as bridged packets on its bridge connection.
This use of a stub network topology offers better performance and flexibility over integrated routing and bridging (IRB). This also helps to avoid a number of issues such as broadcast storms and security risks.
In particular, half-bridging reduces the potential security risks that are associated with normal bridging configurations. Because the ATM interface allocates a single virtual circuit (VC) to a subnet (which could be as small as a single IP address), half-bridging limits the size of the nonsecured network that can be allowed access to the larger routed network. This makes half-bridging configurations ideally suited for customer access points, such digital subscriber lines (DSL).
Note RFC 1483 has been updated and superseded by RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5. However, to avoid confusion, this document continues to use the previously-used terminology of "RFC 1483 ATM half-bridging."
To configure a point-to-multipoint ATM PVC for ATM half-bridging, use the configuration task in the following section.
Note Use the following configuration task when you want to configure point-to-multipoint PVCs for half-bridging operation. Use the configuration task in the next section, "Configuring ATM Routed Bridge Encapsulation," to configure a point-to-point PVC for similar functionality.
ATM RFC 1483 Half-Bridging Configuration Guidelines
When configuring ATM RFC 1483 half-bridging, consider the following guidelines:
•Supports only IP traffic and access lists.
•Supports only fast switching and process switching.
•Supports only PVCs that are configured on multipoint subinterfaces. SVCs are not supported for half-bridging.
•A maximum of one PVC can be configured for half-bridging on each subinterface. Other PVCs can be configured on the same subinterface, as long as they are not configured for half-bridging as well.
•The same PVC cannot be configured for both half-bridging and full bridging.
ATM RFC 1483 Half-Bridging Configuration Task
To configure ATM RFC 1483 half-bridging, perform this task beginning in global configuration mode:
Verifying the ATM RFC 1483 Half-Bridging Configuration
To verify the ATM RFC 1483 half-bridging configuration, use the show atm vc command:
Router# show atm vc 20
ATM4/0/0.20: VCD: 20, VPI: 1, VCI: 20
UBR, PeakRate: 149760
AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0
OAM frequency: 0 second(s)
InARP frequency: 15 minutes(s), 1483-half-bridged-encap
Transmit priority 6
InPkts: 2411, OutPkts: 2347, InBytes: 2242808, OutBytes: 1215746
InPRoc: 226, OutPRoc: 0
InFast: 0, OutFast: 0, InAS: 2185, OutAS: 2347
InPktDrops: 1, OutPktDrops: 0
InByteDrops: 0, OutByteDrops: 0
CrcErrors: 139, SarTimeOuts: 0, OverSizedSDUs: 0, LengthViolation: 0, CPIErrors: 0
Out CLP=1 Pkts: 0
OAM cells received: 0
OAM cells sent: 0
Status: UP
Configuring ATM Routed Bridge Encapsulation
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 (see the "Configuring ATM RFC 1483 Half-Bridging" section).
Note The 1-Port OC-48c/STM-16 ATM SPA does not support RBE.
Use the following configuration task to configure a point-to-point subinterface and PVC for RBE bridging.
Note RFC 1483 has been updated and superseded by RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5.
ATM Routed Bridge Encapsulation Configuration Guidelines
When configuring ATM RBE, consider the following guidelines:
•Supported only on ATM SPAs in a Cisco 7600 SIP-200. RBE is not supported when using a Cisco 7600 SIP-400.
•Supports only AAL5SNAP encapsulation.
•Supports only IP access lists, not MAC-layer access lists.
•Supports only fast switching and process switching.
•Supports distributed Cisco Express Forwarding (dCEF).
•Supports only PVCs on point-to-point subinterfaces. SVCs are not supported for half-bridging.
•The bridge-domain command cannot be used on any PVC that is configured for RBE, because an RBE PVC acts as the termination point for bridged packets.
•The atm bridge-enable command, which was used in previous releases on other ATM interfaces, is not supported on ATM SPA interfaces.
•The IS-IS protocol is not supported with point-to-point PVCs that are configured for RBE bridging.
RBE Configuration Limitation Supports Only One Remote MAC Address
On the Catalyst 6500 Series switch with the Supervisor Engine 720 and the following port adapters, an ATM PVC with an RBE configuration can send packets to only a single MAC address:
•ATM SPA on the Cisco 7600 SIP-200 line card
This restriction occurs because the Catalyst 6500 Series switch keeps only one MAC address attached to an RBE PVC. The MAC address-to-PVC mapping is refreshed when a packet is received from the host. If there are multiple hosts connected to the PVC, the mapping will not be stable and traffic forwarding will be affected.
The solution to this problem is as follows:
1. Configure the ATM PVC for RFC 1483 bridging using the bridge domain vlan x command line interface.
2. Configure an interface vlan vlan x with the IP address of the RBE subinterface.
ATM Routed Bridge Encapsulation Configuration Task
To configure ATM routed bridge encapsulation, perform this task beginning in global configuration mode:
Note The atm route-bridge ip command, like other subinterface configuration commands, is not automatically removed when you delete a subinterface. If you want to remove a subinterface and recreate it without the half-bridging, be sure to manually remove the half-bridging configuration, using the no atm route-bridge ip command.
Verifying the ATM Routed Bridge Encapsulation Configuration
To verify the RBE bridging configuration, use the show ip cache verbose command:
Router# show ip cache verbose
IP routing cache 3 entries, 572 bytes
9 adds, 6 invalidates, 0 refcounts
Minimum invalidation interval 2 seconds, maximum interval 5 seconds,
quiet interval 3 seconds, threshold 0 requests
Invalidation rate 0 in last second, 0 in last 3 seconds
Last full cache invalidation occurred 00:30:34 ago
Prefix/Length Age Interface Next Hop
10.1.0.51/32-24 00:30:10 Ethernet3/1/0 10.1.0.51 14 0001C9F2A81D00600939BB550800
10.8.100.50/32-24 00:00:04 ATM1/1/0.2 10.8.100.50 28 00010000AA030080C2000700000007144F5D201C0800
10.8.101.35/32-24 00:06:09 ATM1/1/0.4 10.8.101.35 28 00020000AA030080C20007000000E01E8D3F901C0800
Configuring RFC 1483 Bridging of Routed Encapsulations
Bridging of routed encapsulations (BRE) enables the ATM SPA to receive RFC 1483 routed encapsulated packets and forward them as Layer 2 frames. In a BRE configuration, the PVC receives the routed PDUs, removes the RFC 1483 routed encapsulation header, and adds an Ethernet MAC header to the packet. The Layer 2 encapsulated packet is then switched by the supervisor engine to the Layer 2 interface determined by the VLAN number and destination MAC.
Note The 1-Port OC-48c/STM-16 ATM SPA does not support bridging.
Figure 7-3 shows a topology where an interface on an ATM SPA receives routed PDUs from the ATM cloud and encapsulates them as Layer 2 frames. It then forwards the frames to the Layer 2 customer device. In this example, the device with the ATM SPA is shown as a Cisco 7600 series router, but it can also be a Catalyst 6500 series switch.
Figure 7-3 Example BRE Topology
RFC 1483 Bridging of Routed Encapsulations Configuration Guidelines
When configuring RFC 1483 bridging of routed encapsulations, consider the following guidelines:
•BRE requires that the ATM SPAs are installed in a Cisco 7600 SIP-200.
•PVCs must use AAL5 encapsulation.
•RFC 1483 bridged PVCs must terminate on the ATM SPA, and the traffic forwarded over this bridged connection to the edge must be forwarded through an Ethernet port.
•To use the Virtual Trunking Protocol (VTP), each main interface should have a subinterface that has been configured for the management VLANs (VLANs 1 and 1002-1005).
•BRE is not supported when using a Cisco 7600 SIP-400.
•Concurrent configuration of RFC 1483 bridging and BRE on the same PVC and VLAN is not supported.
•Bridging between RFC 1483 bridged PVCs is not supported.
•RFC 1483 bridging in a switched virtual circuit (SVC) environment is not supported.
RFC 1483 Bridging of Routed Encapsulations Configuration Task
To configure RFC 1483 bridging of routed encapsulations, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# interface atm slot/subslot/port |
Enters interface configuration mode for the indicated port on the specified ATM SPA. |
Step 2 |
Router(config-if)# no ip address |
Assigns no IP address to the interface. |
Step 3 |
Router(config-if)# spanning-tree bpdufilter enable |
(Optional) Blocks all Spanning Tree BPDUs on the ATM interface. This command should be used if this ATM interface is configured only for BRE VLANs. Note If this ATM interface is configured for both BRE and RFC 1483 bridged VLANs, do not enter this command unless you want to explicitly block BPDUs on the interface. |
Step 4 |
Router(config-if)# no shutdown |
Enables the interface. |
Step 5 |
Router(config-if)# interface atm slot/subslot/port.subinterface point-to-point |
Creates the specified point-to-point subinterface on the given port on the specified ATM SPA, and enters subinterface configuration mode. |
Step 6 |
Router(config-subif)# no ip address |
Assigns no IP address to the subinterface. |
Step 7 |
Router(config-subif)# pvc [name] vpi/vci [ilmi | qsaal] |
Configures a new ATM PVC by assigning its VPI/VCI numbers and enters ATM VC configuration mode. The valid values for vpi/vci are: •vpi—Specifies the VPI ID. The valid range is 0 to 255. •vci—Specifies the VCI ID. The valid range is 1 to 65535. Values 1 to 31 are reserved and should not be used, except for 5 for the QSAAL PVC and 16 for the ILMI PVC. You can also configure the following options: •name—(Optional) An arbitrary string that identifies this PVC. •ilmi—(Optional) Configures the PVC to use ILMI encapsulation (default). •qsaal—(Optional) Configures the PVC to use QSAAL encapsulation. |
Note When using the pvc command, remember that the vpi/vci combination forms a unique identifier for the interface and all of its subinterfaces. If you specify a vpi/vci combination that has been used on another subinterface, the Cisco IOS software assumes that you want to modify that PVC's configuration and automatically switches to its parent subinterface. |
||
Step 8 |
Router(config-if-atm-vc)# bre-connect vlan-id [mac mac-address] |
Enables BRE bridging on the PVC, where: •mac mac-address—(Optional) Specifies the hardware (MAC) address of the destination customer premises equipment (CPE) device at the remote end of the VLAN connection. |
Step 9 |
Router(config-if-atm-vc)# interface gigabitethernet slot/port |
Enters interface configuration mode for the specified Gigabit Ethernet interface. |
Step 10 |
Router(config-if)# switchport |
Configures the Gigabit Ethernet interface for Layer 2 switching. |
Step 11 |
Router(config-if)# switchport access vlan vlan-id |
(Optional) Specifies the default VLAN for the interface. This should be the same VLAN ID that was specified in the bre-connect command in Step 8. |
Step 12 |
Router(config-if)# switchport mode access |
Puts the interface into nontrunking mode. |
Step 13 |
Router(config-if)# end |
Exits interface configuration mode and returns to privileged EXEC mode. |
Verifying the RFC 1483 Bridging of Routed Encapsulations Configuration
Use the following commands to verify the RFC 1483 bridging of routed encapsulations configuration:
Router# show running-config interface atm 5/0/2.1
!
interface ATM5/0/2.1 point-to-point
pvc 0/100
bre-connect 100 ip 10.1.1.2
!
Router# show running-config interface gigabitethernet 1/2
interface GigabitEthernet1/2
no ip address
switchport
switchport access vlan 100
no cdp enable
!
Router# show vlan id 100
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
100 VLAN0100 active Gi1/2, AT5/0/2
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
100 enet 100100 1500 - - - - - 0 0
Router# show atm vlan
Interface Bridge VCD Vlan ID
ATM4/5/0/2.1 1 100
Configuring MPLS over RBE
The ATM SPAs support MLPS over RBE on a Cisco 7600 SIP-200. For more information on RBE, see the "Configuring ATM Routed Bridge Encapsulation" section. To configure both RBE and MPLS on the ATM subinterface, perform this task:
Verifying MPLS over RBE Configuration
Use the following commands to verify MPLS over RBE configuration:
Router#show running interfaces a4/1/0.200
interface ATM4/1/0.200 point-to-point
ip address 3.0.0.2 255.255.0.0
atm route-bridged ip
tag-switching ip
pvc 10/200
!
Router#sh mpls interfaces
Interface IP Tunnel Operational
ATM4/1/0.200 Yes (ldp) No Yes
Router#show mpls ldp bindings
tib entry: 5.0.0.0/16, rev 2
local binding: tag: imp-null
tib entry: 6.0.0.0/16, rev 4
local binding: tag: imp-null
remote binding: tsr: 3.0.0.1:0, tag: imp-null
Router#show mpls ldp neighbor
Peer LDP Ident: 3.0.0.1:0; Local LDP Ident 3.0.0.2:0
TCP connection: 3.0.0.1.646 - 3.0.0.2.11001
State: Oper; Msgs sent/rcvd: 134/131; Downstream
Up time: 01:51:08
LDP discovery sources:
ATM4/1/0.200, Src IP addr: 6.0.0.1
Addresses bound to peer LDP Ident:
6.0.0.1
Router#show mpls forwarding
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 3.0.0.0/16 0 AT4/1/0.200 6.0.0.1
17 Pop tag 16.16.16.16/32 0 AT4/1/0.200 6.0.0.1
18 19 13.13.13.13/32 134 AT4/1/0.200 6.0.0.1 <<<<<
19 Pop tag 17.17.17.17/32 0 PO8/0/0.1 point2point
Configuring Aggregate WRED for PVCs
Weighted Random Early Detection (WRED) is the Cisco implementation of Random Early Detection (RED) for standard Cisco IOS platforms. RED is a congestion-avoidance technique that takes advantage of the congestion-control mechanism of TCP to anticipate and avoid congestion before it occurs. By dropping packets prior to periods of high congestion, RED tells the packet source (usually TCP) to decrease its transmission rate. When configured, WRED can selectively discard lower priority traffic and provide differentiated performance characteristics for different classes of service.
The Aggregate WRED feature provides a means to overcome limitations of WRED implementations that can only support a limited number of unique subclasses. When an interface enables support for aggregate WRED, subclasses that share the same minimum threshold, maximum threshold and mark probability values can be configured into one aggregate subclass based on their IP precedence value or differentiated services code point (DSCP) value. (The DSCP value is the first six bits of the IP type of service [ToS] byte.) You can also define a default aggregate subclass for all subclasses that have not been explicitly defined.
For more complete information on WRED, refer to the Cisco IOS Quality of Service Solutions Configuration Guide.
Aggregate WRED Configuration Guidelines
When configuring aggregate WRED on an ATM SPA interface, consider the following guidelines:
•The Aggregate WRED feature requires that the ATM SPAs are installed in a Cisco 7600 SIP-200 or a Cisco 7600 SIP-400.
•With the Aggregate WRED feature, the previous configuration limitation of a maximum of 6 precedence values per class per WRED policy map is no longer in effect.
•When you configure a policy map class for aggregated WRED on an ATM interface, then you cannot also configure the standard random-detect commands in interface configuration or policy-map class configuration mode.
•Specifying the precedence-based keyword is optional, precedence-based is the default form of aggregate WRED.
•The set of subclass values (IP precedence or DSCP) defined on a random-detect precedence (aggregate) or random-detect dscp (aggregate) CLI will be aggregated into a single hardware WRED resource. The statistics for these subclasses will also be aggregated.
•Defining WRED parameter values for the default aggregate class is optional. If defined, WRED parameters applied to the default aggregate class will be used for all subclasses that have not been explicitly configured. If all possible IP precedence or DSCP values are defined as subclasses, a default specification is unnecessary. If the optional parameters for a default aggregate class are not defined and packets with an unconfigured IP precedence or DSCP value arrive at the interface, these undefined subclass values will be set based on interface (VC) bandwidth.
•After aggregate WRED has been configured in a service policy map, the service policy map must be applied at the ATM VC level (as shown in Step 5 through Step 8 of "Configuring Aggregate WRED Based on IP Precedence").
•The Aggregate WRED feature is not supported in a switched virtual circuit (SVC) environment.
Configuring Aggregate WRED Based on IP Precedence
To configure aggregate WRED to drop packets based on IP precedence values, perform this task beginning in global configuration mode:
Verifying the Precedence-Based Aggregate WRED Configuration
To verify a precedence-based aggregate WRED configuration, use the show policy-map interface command. Note that the statistics for IP precedence values 0 through 3 and 4 and 5 have been aggregated into one line each.
Router# show policy-map interface a4/1/0.10
ATM4/1/0.10: VC 10/110 -
Service-policy output: prec-aggr-wred
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Exp-weight-constant: 9 (1/512)
Mean queue depth: 0
class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
0 1 2 3 0/0 0/0 0/0 10 100 1/10
4 5 0/0 0/0 0/0 40 400 1/10
6 0/0 0/0 0/0 60 600 1/10
7 0/0 0/0 0/0 70 700 1/10
Configuring Aggregate WRED Based on DSCP
To configure aggregate WRED to drop packets based on the differentiated services code point (DSCP) value, perform this task beginning in global configuration mode:
Verifying the DSCP-Based Aggregate WRED Configuration
To verify a DSCP-based aggregate WRED configuration, use the show policy-map interface command. Note that the statistics for DSCP values 0 through 3, 4 through 7, and 8 through 11 have been aggregated into one line each.
Router# show policy-map interface a4/1/0.11
ATM4/1/0.11: VC 11/101 -
Service-policy output: dscp-aggr-wred
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Exp-weight-constant: 0 (1/1)
Mean queue depth: 0
class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
default 0/0 0/0 0/0 1 10 1/10
0 1 2 3
4 5 6 7 0/0 0/0 0/0 10 20 1/10
8 9 10 11 0/0 0/0 0/0 10 40 1/10
Creating and Configuring Switched Virtual Circuits
A switched virtual circuit (SVC) is created and released dynamically, providing user bandwidth on demand. To enable the use of SVCs, you must configure a signaling protocol to be used between the Catalyst 6500 Series switch and the ATM switch. The ATM SPA supports versions 3.0, 3.1, and 4.0 of the User-Network Interface (UNI) signaling protocol, which uses the Integrated Local Management Interface (ILMI) to establish, maintain, and clear the ATM connections at the UNI.
The Catalyst 6500 Series switch does not perform ATM-level call routing when configured for UNI/ILMI operation. Instead, the ATM switch acts as the network and performs the call routing, while the Catalyst 6500 Series switch acts only as the user end-point of the call circuit and only routes packets through the resulting circuit.
Note The 1-Port OC-48c/STM-16 ATM SPA does not support SVCs,
To use UNI/ILMI signaling, you must create an ILMI PVC and a signaling PVC to be used for the SVC call-establishment and call-termination messages between the ATM switch and Catalyst 6500 Series switch. This also requires configuring the ATM interface with a network service access point (NSAP) address that uniquely identifies itself across the network.
The NSAP address consists of a network prefix (13 hexadecimal digits), a unique end station identifier (ESI) of 6 hexadecimal bytes, and a selector byte. If an ILMI PVC exists, the Catalyst 6500 Series switch can obtain the NSAP prefix from the ATM switch, and you must manually configure only the ESI and selector byte. If an ILMI PVC does not exist, or if the ATM switch does not support this feature, you must configure the entire address manually.
To create and configure an SVC, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# interface atm slot/subslot/port |
Enters interface configuration mode for the indicated port on the specified ATM SPA. |
Step 2 |
Router(config-subif)# pvc [name] 0/5 qsaal |
Configures a new ATM PVC to be used for SVC signaling: •name—(Optional) An arbitrary string that identifies this PVC. •vpi—Specifies the VPI ID. The valid range is 0 to 255, but the recommended value for vpi for the signaling PVC is 0. •vci—Specifies the VCI ID. The valid range is 1 to 65535, but the recommended value for vci for the QSAAL signaling PVC is 5. Note The ATM switch must be configured with the same VPI and VCI values for this PVC. •qsaal—Configures the signaling PVC to use QSAAL encapsulation. |
Step 3 |
Router(config-subif)# pvc [name] 0/16 ilmi |
Creates a new ATM PVC to be used for ILMI signaling: •name—(Optional) An arbitrary string that identifies this PVC. •vpi—Specifies the VPI ID. The valid range is 0 to 255, but the recommended value for vpi for the ILMI PVC is 0. •vci—Specifies the VCI ID. The valid range is 1 to 65535, but the recommended value for vci for the ILMI PVC is 16. •ilmi—Configures the PVC to use ILMI encapsulation. |
Note The signaling and ILMI PVCs must be set up on the main ATM interface, not on a subinterface. |
||
Step 4 |
Router(config-if-atm-vc)# exit |
Exits ATM PVC configuration mode and returns to interface configuration mode. |
Step 5 |
Router(config-if)# atm ilmi-keepalive [seconds] [retry counts] |
(Optional) Enables ILMI keepalive messages and sets the interval between them. ILMI keepalive messages are disabled by default. •seconds—(Optional) The amount of time, in seconds, between keepalive messages between the Catalyst 6500 Series switch and the ATM switch. The valid range is 1 to 65535, with a default of 3 seconds. •retry counts—(Optional) Specifies the number of times the Catalyst 6500 Series switch should resend a keepalive message if the first message is unacknowledged. The valid range is 2 to 5, with a default of 4. |
Step 6 |
Router(config-if)# atm esi-address esi.selector |
Specifies the end station ID (ESI) and selector fields for the local portion of the ATM interface's NSAP address, and configures the interface to get the NSAP prefix from the ATM switch. •esi—Specifies a string of 12 hexadecimal digits, in dotted notation, for the ATM interface's ESI value. This value must be unique across the network. •selector—Specifies a string of 2 hexadecimal digits for the selector byte for this ATM interface. To configure the ATM address, you need to enter only the ESI (12 hexadecimal digits) and the selector byte (2 hexadecimal digits). The NSAP prefix (26 hexadecimal digits) is provided by the ATM switch. |
|
or |
or |
Router(config-if)# atm nsap-address nsap-address |
Assigns a complete NSAP address (40 hexadecimal digits) to the ATM interface. The address consists of a network prefix, ESI, and selector byte, and must be in the following format: XX.XXXX.XX.XXXXXX.XXXX.XXXX.XXXX.XXXX.XXXX.XXXX.XX Note The above dotted hexadecimal format provides some validation that the address is a legal value. If you know that the NSAP address is correct, you may omit the dots. |
|
Note The atm esi-address and atm nsap-address commands are mutually exclusive. Configuring the Catalyst 6500 Series switch with one of these commands automatically negates the other. Use the show interface atm command to display the NSAP address that is assigned to the interface. |
||
Step 7 |
Router(config-if)# interface atm slot/subslot/port.subinterface [multipoint | point-to-point] |
(Optional) Creates the specified subinterface on the specified ATM interface, and enters subinterface configuration mode. Note You can create SVCs on either the main ATM interface or on a multipoint subinterface. |
Step 8 |
Router(config-subif)# svc [name] nsap address |
Creates an SVC and specifies the destination NSAP address (40 hexadecimal digits in dotted notation). You can also configure the following option: •name—(Optional) An arbitrary string that identifies this SVC. |
Step 9 |
Router(config-if-atm-vc)# oam-svc [manage] [frequency] |
Enables end-to-end Operation, Administration, and Maintenance (OAM) loopback cell generation and management of the SVC. •manage—(Optional) Enables OAM management of the SVC. •frequency—(Optional) Specifies the delay between transmitting OAM loopback cells. The valid range is 0 to 600 seconds, with a default of 10 seconds. |
Step 10 |
Router(config-if-atm-vc)# protocol protocol {protocol-address | inarp} [[no] broadcast] |
Configures the SVC for a particular protocol and maps it to a specific protocol-address. •protocol—Typically set to either ip or ppp, but other values are possible. •protocol-address—Destination address or virtual interface template for this SVC (if appropriate for the protocol). •inarp—Specifies that the SVC uses Inverse ARP to determine its address. •[no] broadcast—(Optional) Specifies that this mapping should (or should not) be used for broadcast packets. |
Step 11 |
Router(config-if-atm-vc)# encapsulation aal5snap |
(Optional) Configures the ATM adaptation layer (AAL) and encapsulation type. The default and only supported type is aal5snap. |
Note Repeat Step 7 through Step 11 for each SVC to be created. |
||
Step 12 |
Router(config-if-atm-vc)# end |
Exits SVC configuration mode and returns to privileged EXEC mode. |
Verifying the SVC Configuration
Use the show atm svc and show atm ilmi-status commands to verify the configuration of the SVCs that are currently configured on the Catalyst 6500 Series switch.
Router# show atm svc
VCD / Peak Avg/Min Burst
Interface Name VPI VCI Type Encaps SC Kbps Kbps Cells Sts
4/0/0 1 0 5 SVC SAAL UBR 155000 UP
4/0/2 4 0 35 SVC SNAP UBR 155000 UP
4/1/0 16 0 47 SVC SNAP UBR 155000 UP
4/1/0.1 593 0 80 SVC SNAP UBR 155000 UP
Tip To display all SVCs on a particular ATM interface or subinterface, use the show atm svc interface atm command.
To display detailed information about a particular SVC, specify its VPI and VCI values:
Router# show atm svc 0/35
ATM5/1/0.200: VCD: 3384, VPI: 0, VCI: 35, Connection Name: SVC00
UBR, PeakRate: 155000
AAL5-MUX, etype:0x800, Flags: 0x44, VCmode: 0x0
OAM frequency: 10 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Received
OAM VC status: Verified
ILMI VC status: Not Managed
VC is managed by OAM.
InARP DISABLED
Transmit priority 6
InPkts: 0, OutPkts: 4, InBytes: 0, OutBytes: 400
InPRoc: 0, OutPRoc: 4, Broadcasts: 0
InFast: 0, OutFast: 0, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0, LengthViolation: 0, CPIErrors: 0
Out CLP=1 Pkts: 0
OAM cells received: 10
F5 InEndloop: 10, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0
F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0
OAM cells sent: 10
F5 OutEndloop: 10, F5 OutSegloop: 0, F5 OutRDI: 0
F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0
OAM cell drops: 0
Status: UP
TTL: 4
interface = ATM5/1/0.200, call locally initiated, call reference = 8094273
vcnum = 3384, vpi = 0, vci = 35, state = Active(U10)
, point-to-point call
Retry count: Current = 0
timer currently inactive, timer value = 00:00:00
Remote Atm Nsap address: 47.00918100000000107B2B4B01.111155550001.00
, VC owner: ATM_OWNER_SMAP
To display information about the ILMI status and NSAP addresses being used for the SVCs on an ATM interface, use the show atm ilmi-status command:
Router# show atm ilmi-status atm 4/1/0
Interface : ATM4/1/0 Interface Type : Private UNI (User-side)
ILMI VCC : (0, 16) ILMI Keepalive : Enabled/Up (5 Sec 4 Retries)
ILMI State: UpAndNormal
Peer IP Addr: 10.10.13.1 Peer IF Name: ATM 3/0/3
Peer MaxVPIbits: 8 Peer MaxVCIbits: 14
Active Prefix(s) :
47.0091.8100.0000.0010.11b8.c601
End-System Registered Address(s) :
47.0091.8100.0000.0010.11b8.c601.2222.2222.2222.22(Confirmed)
47.0091.8100.0000.0010.11b8.c601.aaaa.aaaa.aaaa.aa(Confirmed)
Tip To display information about the SVC signaling PVC and ILMI PVC, use the show atm pvc 0/5 and show atm pvc 0/16 commands.
Configuring Traffic Parameters for PVCs or SVCs
After creating a PVC or SVC, you can also configure it for the type of traffic quality of service (QoS) class to be used over the circuit:
•Constant Bit Rate (CBR)—Configures the CBR service class and specifies the average cell rate for the PVC or SVC.
•Unspecified Bit Rate (UBR)—Configures the UBR service class and specifies the output peak rate (PCR) for the PVC or SVC. This is the default configuration. SVCs can also be configured with similar input parameters.
•Unspecified Bit Rate Plus (UBR+)—Configures the UBR+ service class and specifies the output peak cell rate (PCR) and minimum cell rate (MCR) for the SVC. SVCs can also be configured with similar input parameters.
Note The 1-Port OC-48c/STM-16 ATM SPA does not support UBR+.
•Variable Bit Rate-Nonreal Time (VBR-nrt)—Configures the VBR-nrt service class and specifies the output PCR, output sustainable cell rate (SCR), and output maximum burst size (MBS) for the PVC or SVC. SVCs can also be configured with similar input parameters.
•Variable Bit Rate-Real Time (VBR-rt)—Configures the VBR-rt service class and the peak rate and average rate burst for the PVC or SVC.
Each service class is assigned a different transmit priority, which the Catalyst 6500 Series switch uses to determine which queued cell is chosen to be transmitted out of an interface during any particular cell time slot. This ensures that real-time QoS classes have a higher likelihood of being transmitted during periods of congestion. Table 7-1 lists the ATM QoS classes and their default transmit priorities.
|
|
---|---|
Signaling, Operation, Administration, and Maintenance (OAM) cells, and other control cells |
0 (highest) |
CBR when greater than 5 percent of the line rate |
1 |
CBR when less than 5 percent of the line rate |
2 |
Voice traffic |
3 |
VBR-rt |
4 |
VBR-nrt |
5 |
UBR |
6 |
Unused and not available or configurable |
7 (lowest) |
1 The default priorities can be changed for individual VCs using the transmit-priority VC configuration command. |
Note When using a CBR VC that exceeds half of the interface line rate, it is possible in some cases that the shaping accuracy for the CBR traffic can drop from 99 percent to 98 percent when the interface is also configured for UBR VCs that are oversubscribed (that is, the UBR VCs are configured for a total line rate that exceeds the interface line rate). If this small drop in accuracy is not acceptable, then we recommend using VBR-rt or VBR-nrt instead of CBR when oversubscribing UBR traffic.
You can configure a PVC or SVC for only one QoS service class. If you enter more than one type, only the most recently configured QoS class takes effect on the circuit.
To configure the traffic parameters for a PVC or SVC, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# interface atm slot/subslot |
Enters interface or subinterface configuration mode for the indicated port on the specified ATM SPA. |
Step 2 |
Router(config-if)# pvc [name] vpi/vci |
Specifies the PVC or SVC to be configured, and enters PVC/SVC configuration mode. |
Note When using the pvc command, remember that the vpi/vci combination forms a unique identifier for the interface and all of its subinterfaces. If you specify a vpi/vci combination that has been used on another subinterface, the Cisco IOS software assumes that you want to modify that PVC's configuration and automatically switches to its parent subinterface. |
||
Step 3 |
Router(config-if-atm-vc)# cbr rate |
Configures constant bit rate (CBR) quality of service (QoS) and average cell rate for the PVC or SVC: •rate—Average cell rate in kbps. The valid range is 48 to 149760 (OC-3) or 599040 (OC-12). |
|
or |
|
Router(config-if-atm-vc)# ubr output-pcr [input-pcr] |
Configures unspecified bit rate (UBR) quality of service (QoS) and peak cell rate (PCR) for the PVC or SVC: •output-pcr—Output PCR in kbps. The valid range is 48 to 149760 (OC-3), 599040 (OC-12), or 2396160 (1-Port OC-48c/STM-16 ATM SPA). •input-pcr—(Optional for SVCs only) Input PCR in kbps. If omitted, input-pcr equals output-pcr. |
|
or |
or |
|
Router(config-if-atm-vc)# vbr-nrt output-pcr output-scr output-mbs [input-pcr] [input-scr] [input-mbs] |
Configures the variable bit rate-nonreal time (VBR-nrt) QoS, the peak cell rate (PCR), sustainable cell rate (SCR), and maximum burst cell size (MBS) for the PVC or SVC: •output-pcr—Output PCR in kbps. The valid range is 48 to 149760 (OC-3), 599040 (OC-12), or 2396160 (1-Port OC-48c/STM-16 ATM SPA). •output-scr—Output SCR in kbps. The valid range is 48 to PCR, and typically is less than the PCR value. •output-mbs—Output MBS in number of cells. The valid range is 1 to 65535, depending on the PCR and SCR values. If the PCR and SCR are configured to the same value, the only valid value for MBS is 1. •input-pcr—(Optional for SVCs only) Input PCR in kbps. •input-scr—(Optional for SVCs only) Input SCR in kbps. •input-mbs—(Optional for SVCs only) Input MBS in number of cells. |
|
or |
or |
|
Router(config-if-atm-vc)# vbr-rt pcr scr burst |
Configures the variable bit rate-real time (VBR-rt) QoS, and the PCR, average cell rate (ACR), and burst cell size (BCS) for the PVC or SVC: •pcr—PCR in kbps. The valid range is 48 to 149760 (OC-3), 599040 (OC-12), or 2396160 (1-Port OC-48c/STM-16 ATM SPA). •scr—SCR in kbps. The valid range is 48 to PCR, and typically is less than the PCR value. •burst—Burst size in number of cells. The valid range is 1 to 65535, depending on the PCR and SCR values. If the PCR and SCR are configured to the same value, the only valid value for burst is 1. |
|
Step 4 |
Router(config-if-atm-vc)# transmit-priority level |
(Optional) Configures the PVC for a new transmit priority level. •level—Priority level from 1 to 6. The default value is determined by the PVC's configured service class (see Table 7-1 for the default levels). |
Note Repeat Step 2 through Step 4 for each PVC or SVC to be configured. |
||
Step 5 |
Router(config-if-atm-vc)# end |
Exits PVC/SVC configuration mode and returns to privileged EXEC mode. |
Verifying the Traffic Parameter Configuration
To verify the configuration of the traffic parameters for a PVC or SVC, use the show atm vc command:
Router# show atm vc 20
ATM1/1/0.200: VCD: 20, VPI: 2, VCI: 200
UBR, PeakRate: 44209
AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0
OAM frequency: 0 second(s)
InARP frequency: 5 minutes(s)
Transmit priority 4
InPkts: 10, OutPkts: 11, InBytes: 680, OutBytes: 708
InPRoc: 10, OutPRoc: 5, Broadcasts: 0
InFast: 0, OutFast: 0, InAS: 0, OutAS: 6
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
OAM cells received: 0
OAM cells sent: 0
Status: UP
To verify the configuration of all PVCs or SVCs on an interface, use the show atm vc interface atm command:
Router# show atm vc interface atm 2/1/0
ATM2/1/0.101: VCD: 201, VPI: 20, VCI: 101
UBR, PeakRate: 149760
AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0
OAM frequency: 0 second(s)
InARP frequency: 15 minutes(s)
Transmit priority 4
InPkts: 3153520, OutPkts: 277787, InBytes: 402748610, OutBytes: 191349235
InPRoc: 0, OutPRoc: 0, Broadcasts: 0
InFast: 211151, OutFast: 0, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 17
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
OAM cells received: 0
OAM cells sent: 0
Status: UP
Configuring Virtual Circuit Classes
When multiple PVCs or SVCs use the same or similar configurations, you can simplify the Catalyst 6500 Series switch's configuration file by creating virtual circuit (VC) classes. Each VC class acts as a template, which you can apply to an ATM interface or subinterface, or to individual PVCs or SVCs.
When you apply a VC class to an ATM interface or subinterface, all PVCs and SVCs created on that interface or subinterface inherit the VC class configuration. When you apply a VC class to an individual PVC or SVC, that particular PVC or SVC inherits the class configuration.
You can then customize individual PVCs and SVCs with further configuration commands. Any commands that you apply to individual PVCs and SVCs take precedence over those of the VC class that were applied to the interface or to the PVC/SVC.
To create and configure a VC class, and then apply it to an interface, subinterface, or individual PVC or SVC, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# vc-class atm vc-class-name |
Creates an ATM virtual circuit (VC) class and enters VC-class configuration mode. •vc-class-name—Arbitrary name to identify this particular VC class. |
Step 2 |
Router(config-vc-class)# configuration-commands |
Enter any PVC or SVC configuration commands for this VC class. See the "Creating a Permanent Virtual Circuit" section and "Creating and Configuring Switched Virtual Circuits" section for additional information. Note You can specify both PVC and SVC configuration commands in the same VC class. If a command is not appropriate for a PVC or SVC, it is ignored when the VC class is assigned to the PVC or SVC. |
Step 3 |
Router(config-vc-class)# interface atm slot/subslot/port |
Enters subinterface configuration mode for the specified ATM interface or subinterface. |
Step 4 |
Router(config-if)# class-int vc-class-name |
(Optional) Applies a VC class on the ATM main interface or subinterface. This class then applies to all PVCs or SVCs that are created on that interface. •vc-class-name—Name of the VC class that was created in Step 1. |
Step 5 |
Router(config-if)# pvc [name] vpi/vci |
Specifies the PVC or SVC to be configured, and enters ATM VC configuration mode. |
Note When using the pvc command, remember that the vpi/vci combination forms a unique identifier for the interface and all of its subinterfaces. If you specify a vpi/vci combination that has been used on another subinterface, the Cisco IOS software assumes that you want to modify that PVC's configuration and automatically switches to its parent subinterface. |
||
Step 6 |
Router(config-if-atm-vc)# class-vc vc-class-name |
Assigns the specified VC class to this PVC or SVC. •vc-class-name—Name of the VC class that was created in Step 1. |
Step 7 |
Router(config-if-atm-vc)# configuration-commands |
Any other VC configuration commands to be applied to this particular PVC or SVC. Commands that are applied to the individual PVC or SVC supersede any conflicting commands that were specified in the VC class. |
Step 8 |
Router(config-if)# end |
Exits interface configuration mode and returns to privileged EXEC mode. |
Verifying the Virtual Circuit Class Configuration
To verify the virtual circuit class configuration, use the show atm vc command:
Router# show atm vc
VCD / Peak Avg/Min Burst
Interface Name VPI VCI Type Encaps SC Kbps Kbps Cells Sts
6/1/0 1 0 5 PVC SAAL UBR 155000 UP
6/1/0 2 0 16 PVC ILMI UBR 155000 UP
6/1/0.1 3 1 32 PVC-D SNAP UBR 155000 UP
6/1/0.2 4 2 32 PVC-D SNAP UBR 155000 UP
Configuring Virtual Circuit Bundles
Virtual circuit bundles are similar to VC classes because they allow you to configure a large group of PVCs by configuring a template (the VC bundle). The main difference between a VC bundle and a VC class is that the VC bundle management allows you to configure multiple VCs that have different QoS characteristics between any pair of ATM-connected switches.
Using VC bundles, you first create an ATM VC bundle and then add VCs to it, and each VC in the bundle can have its own ATM traffic class and ATM traffic parameters. You can configure the VCs collectively at the bundle level, or you can configure the individual VC bundle members. You can also apply a VC class to a bundle to apply the VC class configuration to all of the VCs in the bundle.
You can create differentiated service by mapping one or more MPLS EXP levels to each VC in the bundle, which enables individual VCs in the bundle to carry packets marked with different MPLS EXP levels. The ATM VC bundle manager determines which VC to use for a particular packet by matching the MPLS EXP level of the packet to the MPLS EXP levels assigned to the VCs in the bundle. The bundle manager can also use Weighted Random Early Detection (WRED) or distributed WRED (dWRED) to further differentiate service across traffic that has different MPLS EXP levels.
Virtual Circuit Bundles Configuration Guidelines
•VC bundles are supported only on ATM SPAs in a Cisco 7600 SIP-200. Bundles are not supported for ATM SPAs in a Cisco 7600 SIP-400.
•VC bundles can be used only for PVCs, not SVCs.
•VC bundles require ATM PVC management, as well as Forwarding Information Base (FIB) and Tag Forwarding Information Base (TFIB) switching functionality.
•The Catalyst 6500 Series switch at the remote end of the network must be using a version of Cisco IOS that supports MPLS and ATM PVC management.
Virtual Circuit Bundles Configuration Task
To create and configure a VC bundle and then apply it to an ATM interface or subinterface, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# ip cef [distributed] |
Enables Cisco Express Forwarding (CEF) Layer 3 switching on the Catalyst 6500 Series switch. The Catalyst 6500 Series switch enables CEF by default. •distributed—(Optional) Enables distributed CEF (dCEF). |
Step 2 |
Router(config)# mpls label protocol ldp |
Specifies the default label distribution protocol for a platform. |
Step 3 |
Router(config)# interface atm slot/subslot/port |
Enters interface configuration mode for the specified ATM interface or subinterface. |
Step 4 |
Router(config-if)# mpls ip |
Enables MPLS forwarding of IPv4 packets along normally routed paths for the interface. |
Step 5 |
Router(config-if)# bundle bundle-name |
Creates an ATM virtual circuit (VC) bundle and enters bundle configuration mode. •bundle-name—Arbitrary name to identify this particular VC bundle. |
Step 6 |
Router(config-if-atm-bundle)# class-bundle vc-class-name |
(Optional) Applies a VC class to this bundle. The class configuration is then applied to all VCs in the bundle. •vc-class-name—Name of the VC class to be applied to this bundle and its PVCs or SVCs. See the "Configuring Virtual Circuit Classes" section for information on creating VC classes. |
Step 7 |
Router(config-if-atm-bundle)# configuration-commands |
Enter any other PVC or SVC configuration commands for this VC bundle. See "Creating a Permanent Virtual Circuit" section and "Creating and Configuring Switched Virtual Circuits" section for additional information. |
Note Configuration commands applied directly to the VC bundle supersede a configuration that is applied through a VC class. |
||
Step 8 |
Router(config-if-atm-bundle)# pvc-bundle [name] vpi/vci |
Creates a member PVC of the bundle and enters PVC bundle configuration mode. |
Step 9 |
Router(config-if-atm-member)# mpls experimental [level | other | range] |
(Optional) Configures the MPLS EXP levels for the PVC bundle member. •level—MPLS EXP level for the PVC bundle member. The valid range is 0 to 7. •other—Any MPLS EXP levels in the range from 0 to 7 that are not explicitly configured (default). •range—A range of MPLS EXP levels between 0 and 7, separated by a hyphen. |
Step 10 |
Router(config-if-atm-member)# bump {implicit | explicit precedence-level | traffic} |
(Optional) Configures the bumping rules for the PVC bundle member. •implicit—Bumped traffic is carried by a VC with a lower precedence (default). •explicit precedence-level—Specifies the precedence level of the traffic that should be bumped when the PVC member goes down. The precedence-level can range from 0 to 9. •traffic—The PVC member accepts bumped traffic (default). Use no bump traffic to specify that the PVC member does not accept bumped traffic. |
Step 11 |
Router(config-if-atm-member)# protect {group | vc} |
(Optional) Specifies that the PVC bundle member is protected. •group—Specifies that the PVC bundle member is part of a protected group. When all members of a protected group go down, the bundle goes down. •vc—Specifies that the PVC bundle member is individually protected. When a protected VC goes down, it also takes the bundle down. By default, PVC bundle members are not protected. |
Step 12 |
Router(config-if-atm-member)# configuration-commands |
Any other VC configuration commands to be applied to this particular VC bundle member. Commands that are applied to a bundle member supersede any conflicting commands that were specified in the VC class or VC bundle. |
Note Repeat Step 8 through Step 12 for each PVC member of the bundle to be created. |
||
Step 13 |
Router(config-if-atm-member)# end |
Exits interface configuration mode and returns to privileged EXEC mode. |
Verifying the Virtual Circuit Bundles Configuration
To verify the configuration of the virtual circuit bundles, display the configuration for its interface or subinterface, use the show running-config interface atm command, as in the following example:
Router# show running-config interface atm 4/1/0.2
interface ATM4/1/0.2 point-to-point
ip address 10.10.10.1 255.255.255.0
no ip directed-broadcast
no atm enable-ilmi-trap
bundle ABC
class-bundle bundle-class
pvc-bundle ABC-high 1/107
class-vc high
pvc-bundle ABC-med 1/105
class-vc med
pvc-bundle ABC-low 1/102
class-vc low
!
!
To verify the operation and current status of a virtual circuit bundle, specify the bundle name with the show atm bundle command:
Router# show atm bundle ABC
ABC on ATM4/1/0.2: UP
Config Current Bumping PG/ Peak Avg/Min Burst
VC Name VPI/ VCI Prec/Exp Prec/Exp PrecExp/ PV Kbps kbps Cells Sts
Accept
ABC-high 1/107 7 7 - / Yes PV 10000 5000 32 UP
ABC-med 1/105 6 6 - / Yes PV 10000 UP
ABC-low 1/102 5-0 5-0 - / Yes - 10000 UP
Configuring Multi-VLAN to VC Support
For information on configuring multi-VLAN to VC support, see the "Configuring QoS for ATM VC Access Trunk Emulation" topic at http://www.cisco.rw/univercd/cc/td/doc/product/ core/cis7600/cfgnotes/flexport/combo/flexqos.htm#wp1162305.
Configuring Link Fragmentation and Interleaving with Virtual Templates
The ATM SPA supports Link Fragmentation and Interleaving (LFI) with the distributed Compressed Real-Time Protocol (dCRTP). This allows the ATM interfaces, which are cell-based, to efficiently transport packet-based IP traffic without an excessive amount of bandwidth being used for packet headers and other overhead.
The LFI/dCRTP feature requires the use of multilink PPP (MLP), which can be implemented either by using virtual templates or dialer templates.
Link Fragmentation and Interleaving with Virtual Templates Configuration Guidelines
•The 1-Port OC-48c/STM-16 ATM SPA does not support LFI.
•A functional multilink PPP (MLP) bundle requires one virtual access interface operating as a PPP interface, and a second virtual access interface operating as a multilink PPP bundle interface.
•The Cisco IOS software supports a maximum of 1,000 virtual template interfaces per Catalyst 6500 Series switch.
•When LFI is configured on a PVC, the output packets counter in the show atm pvc command counts all fragments of a packet as a single packet, and does not display the actual number of fragmented packets that were output. For example, if a packet is fragmented into four fragments, the output packets counter shows only one packet, not four. The output bytes counter is accurate, however, and you can also display the total number of fragmented packets on all PVCs on the interface with the show interface atm command.
• LFI supports three protocol formats: AAL5CISCOPP, AAL5MUX, and AAL5SNAP
•For fragmentation to function, a QoS service policy having a minimum of two QoS queues must be applied to the virtual template interface.
Link Fragmentation and Interleaving with Virtual Templates Configuration Task
To configure LFI with virtual templates, perform this task beginning in global configuration mode:
Verifying the Link Fragmentation and Interleaving with Virtual Templates Configuration
To verify a virtual template configuration, display the running configuration for the configured ATM and virtual interfaces:
Router# show running-config interface virtual-template 1
!
interface Virtual-Template1
Current configuration : 373 bytes
!
interface Virtual-Template1
bandwidth 300
ip address 23.0.0.1 255.255.255.0
ppp chap hostname template1
ppp multilink
ppp multilink fragment-delay 8
ppp multilink interleave
service-policy output lfiqos
!
Router# show running-config interface atm 6/0/1
!
interface ATM6/0/1
atm idle-cell-format itu
atm enable-payload-scrambling
no atm ilmi-keepalive
pvc 32/32
vbr-rt 640 640 256
encapsulation aal5snap
protocol ppp Virtual-Template1
To display run-time statistics and other information about the currently configured multilink PPP bundles, use the show ppp multilink command:
Router# show ppp multilink
Virtual-Access3, bundle name is north-2
Bundle up for 00:01:51
Bundle is Distributed
0 lost fragments, 0 reordered, 0 unassigned
0 discarded, 0 lost received, 1/255 load
0x0 received sequence, 0x0 sent sequence
Member links: 1 (max not set, min not set)
Vi1, since 00:01:38, no frags rcvd, 62 weight, 54 frag size
dLFI statistics:
DLFI Packets Pkts In Pkts Out
Fragmented 4294967288 3129990
UnFragmented 1249071 0
Reassembled 1249071 1564994
Reassembly Drops 0
Fragmentation Drops 0
Out of Seq Frags 0
Note The show ppp multilink command displays only the packet counters, and not byte counters, for a dLFI configuration on an ATM SPA interface. Also, the number of fragmented packets shows the number of fragments sent to the SAR assembly, not the number of fragments that are placed on the ATM line. It is possible that the SAR assembly might drop some of these fragments on the basis of Layer 3 QoS limits.
Configuring the Distributed Compressed Real-Time Protocol
The distributed Compressed Real-Time Protocol (dCRTP) compresses the 40 bytes of the IP/UDP/RTP packet headers down to between only two and four bytes in a distributed fast-switching and distributed Cisco Express Forwarding (dCEF) network. This compression reduces the packet size, improves the speed of packet transmission, and reduces packet latency, especially on cell-based interfaces, such as ATM interfaces.
Distributed Compressed Real-Time Protocol Configuration Guidelines
When configuring dCRTP, consider the following guidelines:
•Distributed CEF switching or distributed fast switching must be enabled on the interface.
•PPP must be used on the interface or subinterface.
Distributed Compressed Real-Time Protocol Configuration Task
To enable and configure dCRTP on an ATM interface, virtual template interface, or a dialer template interface, perform this task beginning in global configuration mode:
Verifying the Distributed Compressed Real-Time Protocol Configuration
To verify the dCRTP of an ATM interface, use the show running-config interface interface virtual-template command:
Router# show running-config interface interface virtual-template 1
!
interface Virtual-Template1
bandwidth 2320
ip unnumbered Loopback2
max-reserved-bandwidth 100
ip tcp header-compression
ppp multilink
ppp multilink fragment delay 4
ppp multilink interleave
ip rtp header-compression
Configuring Automatic Protection Switching
The ATM SPAs support 1+1 Automatic Protection Switching (APS) on PVCs as described in section 5.3 of the Telcordia publication GR-253-CORE SONET Transport Systems: Common Generic Criteria. APS redundancy is supported at the line layer, so that when an OC-3c, OC-12c, or OC-48c link fails, all of the PVCs that are carried by that link are switched simultaneously.
Note APS is not supported for SVCs.
In an APS configuration, a redundant ATM interface (the Protect interface) is configured for every active ATM interface (the Working interface). If the Working interface goes down, the Protect interface automatically switches over and continues communication over the interface's PVCs.
The APS Protect Group Protocol (PGP), which runs on top of User Datagram Protocol (UDP), provides communication between the Working and Protect interfaces. This communication occurs over a separate out-of-band (OOB) communication channel, such as an Ethernet link.
In the case of degradation, loss of channel signal, or manual intervention, the APS software on the Protect interface sends APS PGP commands to activate or deactivate the Working interface as necessary. If the communication channel between the Working and Protect interfaces is lost, the Working interface assumes full control, as if no Protect interface existed.
Note In the following figures, the devices with the ATM SPAs are shown as Cisco 7600 series routers, but they can also be Catalyst 6500 series switches.
Figure 7-4 shows a very simple example of a pair of Working and Protect interfaces on a single router.
Figure 7-4 Basic Automatic Protection Switching Configuration
Tip If possible, use separate SPAs to provide the Working and Protect interfaces, as shown in Figure 7-4. This removes the SPA as a potential single point of failure, which would be the case if the same SPA provided both the Working and Protect interfaces.
Multiple switches can be using APS at the same time. For example, Figure 7-5 shows a simple example of two routers that each have one pair of Working and Protect interfaces. In this configuration, the two routers are independently configured.
Figure 7-5 Sample Automatic Protection Switching Configuration with Multiple Routers
You can also configure multiple routers with APS so that interfaces on one router can provide protection for the interfaces on another router. This provides protection in case a router experiences a major system problem, such as a processor fault.
Figure 7-6 shows a basic example of two routers that each have one Working ATM interface. Each router also has one Protect interface that provides protection for the other router's Working interface. Note that this configuration requires a separate out-of-band (OOB) communication link between the two routers, which in this case is provided by the Ethernet network.
Figure 7-6 Sample Multiple Router Protection with Automatic Protection Switching
An APS configuration requires the following steps:
•Configure the Working interface with the desired IP addresses, subinterfaces, and PVCs. Also assign the interface to an APS group and designate it as the Working interface.
•Create a loopback circuit for communication between the Working and Protect interfaces. This is optional, because you can also use any valid IP address on the router. However, we recommend using a loopback interface because it is always up and provides connectivity between the two interfaces as long as any communication path exists between them.
•Configure the Protect interface with the same subinterfaces and PVCs that were configured on the Working interface. The Protect interface should also be configured with an IP address that is on the same subnet as the Working interface.
Tip Always configure the Working interface before the Protect interface, so as to prevent the Protect interface from becoming active and disabling the circuits on the Working interface.
Automatic Protection Switching Configuration Guidelines
When configuring APS, consider the following guidelines:
•The Working and Protect interfaces must be compatible (that is, both OC-3c or both OC-12c interfaces). The interfaces can be on the same SPA, different SPAs in the same router, or different SPAs in different routers.
•If using interfaces on different routers, the two routers must have a network connection other than the ATM connection (such as through an Ethernet LAN). Because the APS PGP is UDP traffic, this network connection should be reliable with a minimum number of hops.
•Configure the Working ATM interface with the desired IP addresses and other parameters, as described in the "Required Configuration Tasks" section and the "Configuring SONET and SDH Framing" section.
•Configure the desired PVCs on the Working interface, as described in the different procedures that are listed in the "Creating a Permanent Virtual Circuit" section.
•The IP addresses on the Working and Protect interfaces should be in the same subnet.
•APS is not supported on SVCs.
Automatic Protection Switching Configuration Task
To configure the Working and Protect interfaces on the ATM SPAs for basic APS operation, perform this task beginning in global configuration mode. For complete information on APS, including information on additional APS features, refer to the "Configuring Serial Interfaces" chapter in the Cisco IOS Interface Configuration Guide, Release 12.2.
|
|
|
---|---|---|
Step 1 |
Router(config)# interface loopback interface-number |
Creates a loopback interface and enters interface configuration mode: •interface-number—An arbitrary value from 0 to 2,147,483,647 that uniquely identifies this loopback interface. |
Step 2 |
Router(config-if)# ip address ip-address mask [secondary] |
Specifies the IP address and subnet mask for this loopback interface. If the Working and Protect interfaces are on the same router, this IP address should be in the same subnet as the Working interface. If the Working and Protect interfaces are on different routers, this IP address should be in the same subnet as the Ethernet interface that provides the connectivity between the two routers. Repeat this command with the secondary keyword to specify additional IP addresses to be used for this interface. |
Step 3 |
Router(config-if)# interface atm slot/subslot/port |
Enters interface configuration mode for the Working interface on the ATM SPA. |
Step 4 |
Router(config-if)# ip address ip-address mask [secondary] |
Specifies the IP address and subnet mask for the Working interface. Repeat this command with the secondary keyword to specify additional IP addresses to be used for the interface. |
Step 5 |
Router(config-if)# aps group group-number |
Enables the use of the APS Protect Group Protocol for this Working interface. •group-number—Unique number identifying this pair of Working and Protect interfaces. Note The aps group command is optional if this is the only pair of Working and Protect interfaces on the router, but is required when you configure more than one pair of Working and Protect interfaces on the same router. |
Step 6 |
Router(config-if)# aps working circuit-number |
Identifies the interface as the Working interface. •circuit-number—Identification number for this particular channel in the APS pair. Because only 1+1 redundancy is supported, the only valid values are 0 or 1, and the Working interface defaults to 1. |
Step 7 |
Router(config-if)# aps authentication security-string |
(Optional) Specifies a security string that must be included in every OOB message sent between the Working and Protect interfaces. •security-string—Arbitrary string to be used as a password between the Working and Protect interfaces. This string must match the one configured on the Protect interface. |
Step 8 |
Router(config-if)# interface atm slot/subslot/port |
Enters interface configuration mode for the Protect interface on the ATM SPA. |
Step 9 |
Router(config-if)# ip address ip-address mask [secondary] |
Specifies the IP address and subnet mask for the Protect interface. Note This should be the same address that was configured on the Working interface in Step 4. Repeat this command with the secondary keyword to specify additional IP addresses to be used for the interface. These should match the secondary IP addresses that are configured on the Working interface. |
Step 10 |
Router(config-if)# aps group group-number |
Enables the use of the APS Protect Group Protocol for this Protect interface. •group-number—Unique number identifying this pair of Working and Protect interfaces. Note The aps group command is optional if this is the only pair of Working and Protect interfaces on the router, but is required when you configure more than one pair of Working and Protect interfaces on the same router. |
Step 11 |
Router(config-if)# aps protect circuit-number ip-address |
Identifies this interface as the Protect interface: •circuit-number—Identification number for this particular channel in the APS pair. Because only 1+1 redundancy is supported, the only valid values are 0 or 1, and the Protect interface defaults to 0. •ip-address—IP address for the loopback interface that was configured in Step 2. The Protect interface uses this IP address to communicate with the Working interface. Note If you do not want to use a loopback interface for this configuration, this IP address should be the address of the Working interface if the Protect and Working interfaces are on the same router. If the Working and Protect interfaces are on different routers, this should be the IP address of the Ethernet interface that provides interconnectivity between the two routers. |
Step 12 |
Router(config-if)# aps authentication security-string |
(Optional) Specifies a security string that must be included in every OOB message sent between the Working and Protect interfaces. •security-string—Arbitrary string to be used as a password between the Working and Protect interfaces. This string must match the one configured on the Working interface. |
Step 13 |
Router(config-if)# aps revert minutes |
(Optional) Enables the Protect interface to automatically switch back to the Working interface after the Working interface has been up for a specified number of minutes. •minutes—Number of minutes until the interface is switched back to the Working interface after the Working interface comes back up. Note If this command is not given, you must manually switch back to the Working interface using either the aps force circuit-number or the aps manual circuit-number command. |
Step 14 |
Router(config-if)# end |
Exits interface configuration mode and returns to privileged EXEC mode. |
Verifying the Automatic Protection Switching Configuration
To verify the APS configuration on the router, use the show aps command without any options. The following example shows a typical configuration in which the Working interface is the active interface:
Router# show aps
ATM4/0/1 APS Group 1: protect channel 0 (inactive)
bidirectional, revertive (2 min)
PGP timers (default): hello time=1; hold time=3
state:
authentication = (default)
PGP versions (native/negotiated): 2/2
SONET framing; SONET APS signalling by default
Received K1K2: 0x00 0x05
No Request (Null)
Transmitted K1K2: 0x20 0x05
Reverse Request (protect)
Working channel 1 at 10.10.10.41 Enabled
Remote APS configuration: (null)
ATM4/0/0 APS Group 1: working channel 1 (active)
PGP timers (from protect): hello time=3; hold time=6
state: Enabled
authentication = (default)
PGP versions (native/negotiated): 2/2
SONET framing; SONET APS signalling by default
Protect at 10.10.10.41
Remote APS configuration: (null)
The following sample output is for the same interfaces, except that the Working interface has gone down and the Protect interface is now active:
Router# show aps
ATM4/0/1 APS Group 1: protect channel 0 (active)
bidirectional, revertive (2 min)
PGP timers (default): hello time=1; hold time=3
state:
authentication = (default)
PGP versions (native/negotiated): 2/2
SONET framing; SONET APS signalling by default
Received K1K2: 0x00 0x05
No Request (Null)
Transmitted K1K2: 0xC1 0x05
Signal Failure - Low Priority (working)
Working channel 1 at 10.10.10.41 Disabled SF
Pending local request(s):
0xC (, channel(s) 1)
Remote APS configuration: (null)
ATM4/0/0 APS Group 1: working channel 1 (Interface down)
PGP timers (from protect): hello time=3; hold time=6
state: Disabled
authentication = (default)
PGP versions (native/negotiated): 2/2
SONET framing; SONET APS signalling by default
Protect at 10.10.10.41
Remote APS configuration: (null)
Tip To obtain APS information for a specific ATM interface, use the show aps atm slot/subslot/port command. To display information about the APS groups that are configured on the router, use the show aps group command.
Configuring SONET and SDH Framing
The default framing on the ATM OC-3c and OC-12c SPAs is SONET, but the interfaces also support SDH framing.
Note In ATM environments, the key difference between SONET and SDH framing modes is the type of cell transmitted when no user or data cells are available. The ATM forum specifies the use of idle cells when unassigned cells are not being generated. More specifically, in Synchronous Transport Module-X (STM-X) mode, an ATM interface sends idle cells for cell-rate decoupling. In Synchronous Transport Signal-Xc (STS-Xc) mode, the ATM interface sends unassigned cells for cell-rate decoupling.
To change the framing type and configure optional parameters, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# interface atm slot/subslot/port |
Enters interface configuration mode for the indicated port on the specified ATM SPAs. |
Step 2 |
Router(config-if)# atm clock internal |
(Optional) Configures the interface to use its own internal (onboard) clock to clock transmitted data. The default (no atm clock internal) configures the interface to use the transmit clock signal that is recovered from the receive data stream, allowing the switch to provide the clocking source. |
Step 3 |
Router(config-if)# atm framing {sdh | sonet} |
(Optional) Configures the interface for either SDH or SONET framing. The default is SONET. |
Step 4 |
Router(config-if)# [no] atm sonet report {all | b1-tca | b2-tca | b3-tca | default | lais | lrdi | pais | plop | pplm | prdi | ptim | puneq | sd-ber | sf-ber | slof | slos} |
(Optional) Enables ATM SONET alarm reporting on the interface. The default is for all reports to be disabled. You can enable an individual alarm, or you can enable all alarms with the all keyword. Note This command also supports a none [ignore] option, which cannot be used with any of the other options. See the "Configuring for Transmit-Only Mode" section for details. |
Step 5 |
Router(config-if)# no] atm sonet-threshold {b1-tca value | b2-tca value | b3-tca value | sd-ber value | sf-ber value} |
(Optional) Configures the BER threshold values on the interface. The value specifies a negative exponent to the power of 10 (10 to the power of minus value) for the threshold value. The default values are the following: •b1-tca = 6 (10e-6) •b2-tca = 6 (10e-6) •b3-tca = 6 (10e-6) •sd-ber = 6 (10e-6) •sf-ber = 3 (10e-3) |
Step 6 |
Router(config-if)# end |
Exits interface configuration mode and returns to privileged EXEC mode. |
Verifying the SONET and SDH Framing Configuration
To verify the framing configuration, use the show controllers atm command:
Router# show controllers atm 5/0/1
Interface ATM5/0/1 is up
Framing mode: SONET OC3 STS-3c
SONET Subblock:
SECTION
LOF = 0 LOS = 0 BIP(B1) = 603
LINE
AIS = 0 RDI = 2 FEBE = 2332 BIP(B2) = 1018
PATH
AIS = 0 RDI = 1 FEBE = 28 BIP(B3) = 228
LOP = 0 NEWPTR = 0 PSE = 1 NSE = 2
Active Defects: None
Active Alarms: None
Alarm reporting enabled for: LOF LOS B1-TCA B2-TCA SF LOP B3-TCA
ATM framing errors:
HCS (correctable): 0
HCS (uncorrectable): 0
APS
COAPS = 0 PSBF = 0
State: PSBF_state = False
Rx(K1/K2): 00/00 Tx(K1/K2): 00/00
Rx Synchronization Status S1 = 00
S1S0 = 00, C2 = 00
PATH TRACE BUFFER : STABLE
BER thresholds: SF = 10e-3 SD = 10e-6
TCA thresholds: B1 = 10e-7 B2 = 10e-6 B3 = 10e-6
Clock source: line
Configuring for Transmit-Only Mode
The ATM SPAs support operation in a transmit-only mode, where a receive fiber does not need to be connected. This mode is typically used for one-way applications, such as video-on-demand.
By default, the lack of a receive path generates continuous framing errors, which bring the ATM interface down. To prevent this, you must configure the ATM interface to disable and ignore all ATM SONET alarms. The 1-Port OC-48c/STM-16 ATM SPA default framing is sonet
Note This configuration violates the ATM specifications for alarm reporting.
Transmit-Only Mode Configuration Guidelines
When an ATM interface has been configured to ignore ATM SONET alarms, you cannot configure an IP address (or other Layer 3 parameter) on the interface. Similarly, you must remove all IP addresses (and all other Layer 3 parameters) from the interface before beginning this procedure.
Transmit-Only Mode Configuration Task
To configure the ATM interface to disable and ignore all ATM SONET alarms, perform this task beginning in global configuration mode:
Saving the Configuration
To save your running configuration to nonvolatile random-access memory (NVRAM), use the following command in privileged EXEC configuration mode:
|
|
---|---|
Router# copy running-config startup-config |
Writes the new configuration to NVRAM. |
Note To permanently save your configuration changes, you must write them to the nonvolatile RAM (NVRAM) by entering the copy running-config startup-config command in privileged EXEC mode.
For more information about managing configuration files, refer to the Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.2 and Cisco IOS Configuration Fundamentals Command Reference, Release 12.2 publications.
Shutting Down and Restarting an Interface on a SPA
Shutting down an interface puts it into the administratively down mode and takes it offline, stopping all traffic that is passing through the interface. Shutting down an interface, though, does not change the interface configuration.
As a general rule, you do not need to shut down an interface if you are removing it and replacing it with the same exact model of SPA in an online insertion and removal (OIR) operation. However, we recommend shutting down an interface whenever you are performing one of the following tasks:
•When you do not need to use the interface in the network.
•Preparing for future testing or troubleshooting.
•Changing the interface configuration in a way that would affect the traffic flow, such as changing the encapsulation.
•Changing the interface cables.
•Removing a SPA that you do not expect to replace.
•Replacing the SIP with another type of SIP (such as replacing a Cisco 7600 SIP-200 with a Cisco 7600 SIP-400.
•Replacing an interface card with a different model of card.
Shutting down the interface in these situations prevents anomalies from occurring when you reinstall the new card or cables. It also reduces the number of error messages and system messages that might otherwise appear.
Tip If you are planning on physically removing the SPA from the SIP, also shut down the SPA, using the procedure given in the "Shutting Down an ATM Shared Port Adapter" section.
Note If you plan to replace an existing ATM port adapter with an ATM SPA in the Catalyst 6500 Series switch and want to use the same configuration, save the slot's configuration before physically replacing the hardware. This is because all slot configuration is lost when you replace one card type with another card type, even if the two cards are functionally equivalent. You can then reenter the previous configuration after you have inserted the ATM SPA.
To shut down an interface, perform this task beginning in global configuration mode:
|
|
|
---|---|---|
Step 1 |
Router(config)# interface atm slot/subslot/port |
Enters interface configuration mode for the indicated port on the specified ATM SPA. |
Step 2 |
Router(config-if)# shutdown |
Shuts down the interface. |
Repeat Step 1 and Step 2 for each interface to be shut down. |
||
Step 3 |
Router(config-if)# end |
Exits interface configuration mode and returns to privileged EXEC mode. |
Tip When you shut down an interface, the show interface command indicates that the interface is administratively down until the SPA is physically removed from the chassis or until the SPA is re-enabled.
The following shows a typical example of shutting down an ATM SPA interface:
Router> enable
Router# configure terminal
Router(config)# interface atm 4/0/0
Router(config-if)# shutdown
Router(config-if)# end
Router# show interface atm 4/0/0
ATM4/0/0 is administratively down, line protocol is down
Hardware is SPA-4XOC3-ATM, address is 000d.2959.d5ca (bia 000d.2959.d5ca)
Internet address is 10.10.10.16/24
MTU 4470 bytes, sub MTU 4470, BW 599040 Kbit, DLY 80 usec,
reliability 255/255, txload 42/255, rxload 1/255
Encapsulation ATM, loopback not set
Encapsulation(s): AAL5
4095 maximum active VCs, 1 current VCCs
VC idle disconnect time: 300 seconds
0 carrier transitions
Last input 01:01:16, output 01:01:16, output hang never
Last clearing of "show interface" counters 01:10:21
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 702176000 bits/sec, 1415679 packets/sec
1000 packets input, 112000 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
2948203354 packets output, 182788653886 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Shutting Down an ATM Shared Port Adapter
Shutting down an ATM SPA shuts down all ATM interfaces on the SPA, and puts the SPA and its interfaces into the administratively down state. This takes all interfaces offline, stopping all traffic that is passing through the SPA. Shutting down an ATM SPA, though, does not change the configuration of the SPA and its interfaces.
As a general rule, you do not need to shut down an ATM SPA if you are removing it and replacing it with the same exact model of SPA, in an online insertion and removal (OIR) operation. However, you should shut down the ATM SPA whenever you are performing one of the following tasks:
•Removing an interface that you do not expect to replace.
•Replacing the SIP with another type of SIP (such as replacing a Cisco 7600 SIP-200 with a Cisco 7600 SIP-400).
•Replacing the ATM SPA with a different model of SPA.
To shut down the ATM SPA, perform this task beginning in global configuration mode:
The following shows a typical example of shutting down ATM SPAs. In this example, the SPA in subslot 0 is put into the reset mode, while the SPA in subslot 1 is powered down.
Router> enable
Router# hw-module subslot 4/0 shutdown powered
Router# hw-module subslot 4/1 shutdown unpowered
Router#
Tip The ATM SPA remains shut down, even after a new card is installed or after a reset of the Catalyst 6500 Series switch, until you re-enable the SPA using the no hw-module subslot shutdown command.
Verifying the Interface Configuration
See the following sections to obtain configuration and operational information about the ATM SPA and its interfaces:
•Verifying Per-Port Interface Status
•Monitoring Per-Port Interface Statistics
For additional information on using these and other commands to obtain information about the configuration and operation of the ATM SPA and interfaces, see Chapter 8 "Troubleshooting the ATM SPAs."
Verifying Per-Port Interface Status
Use the show interfaces atm command to display detailed status information about an interface port in an ATM SPA that is installed in the Catalyst 6500 Series switch. The following example provides sample output for interface port 1 (the second port) on the ATM SPA that is located in subslot 0 (the left-most subslot), of the SIP that is installed in slot 3 of a Catalyst 6500 Series switch:
Router# show interface atm 3/0/1
ATM3/0/1 is up, line protocol is up
Hardware is SPA-4XOC3-ATM, address is 000a.f330.7dc0 (bia 000a.f330.7dca)
Internet address is 10.13.21.31/24
MTU 4470 bytes, sub MTU 4470, BW 599040 Kbit, DLY 80 usec,
reliability 255/255, txload 140/255, rxload 129/255
Encapsulation ATM, loopback not set
Encapsulation(s): AAL5
4095 maximum active VCs, 1 current VCCs
VC idle disconnect time: 300 seconds
0 carrier transitions
Last input never, output never, output hang never
Last clearing of "show interface" counters 00:45:35
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 304387000 bits/sec, 396342 packets/sec
5 minute output rate 329747000 bits/sec, 396334 packets/sec
1239456438 packets input, 118987818048 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
1239456287 packets output, 128903453848 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Monitoring Per-Port Interface Statistics
Use the show controllers atm command to display detailed status and statistical information on a per-port basis for an ATM SPA. The following example provides sample output for interface port 0 (the first port) on the ATM SPA that is located in subslot 0 (the left-most subslot) of the SIP that is installed in slot 4 of a Catalyst 6500 Series switch:
Router# show controllers atm 4/0/0
Interface ATM4/0/0 is up
Framing mode: SONET OC3 STS-3c
SONET Subblock:
SECTION
LOF = 0 LOS = 0 BIP(B1) = 603
LINE
AIS = 0 RDI = 2 FEBE = 2332 BIP(B2) = 1018
PATH
AIS = 0 RDI = 1 FEBE = 28 BIP(B3) = 228
LOP = 0 NEWPTR = 0 PSE = 1 NSE = 2
Active Defects: None
Active Alarms: None
Alarm reporting enabled for: SF SLOS SLOF B1-TCA B2-TCA PLOP B3-TCA
ATM framing errors:
HCS (correctable): 0
HCS (uncorrectable): 0
APS
COAPS = 0 PSBF = 0
State: PSBF_state = False
Rx(K1/K2): 00/00 Tx(K1/K2): 00/00
Rx Synchronization Status S1 = 00
S1S0 = 00, C2 = 00
PATH TRACE BUFFER : STABLE
Remote hostname : fecao7609_2
Remote interface: ATM9/0/0
Remote IP addr : 0.0.0.0
Remote Rx(K1/K2): 00/00 Tx(K1/K2): 00/00
BER thresholds: SF = 10e-3 SD = 10e-6
TCA thresholds: B1 = 10e-6 B2 = 10e-6 B3 = 10e-6
Clock source: line
Configuration Examples
This section includes the following configuration examples for the ATM SPAs:
•Basic Interface Configuration Example
•Permanent Virtual Circuit Configuration Example
•PVC on a Point-to-Point Subinterface Configuration Example
•PVC on a Multipoint Subinterface Configuration Example
•RFC 1483 Bridging for PVCs Configuration Example
•RFC 1483 Bridging for PVCs with IEEE 802.1Q Tunneling Configuration Example
•ATM RFC 1483 Half-Bridging Configuration Example
•ATM Routed Bridge Encapsulation Configuration Example
•ATM RFC 1483 Half-Bridging Configuration Example
•ATM Routed Bridge Encapsulation Configuration Example
•Precedence-Based Aggregate WRED Configuration Example
•DSCP-Based Aggregate WRED Configuration Example
•Switched Virtual Circuits Configuration Example
•Traffic Parameters for PVCs or SVCs Configuration Example
•Virtual Circuit Classes Configuration Example
•Virtual Circuit Bundles Configuration Example
•Link Fragmentation and Interleaving with Virtual Templates Configuration Example
•Distributed Compressed Real-Time Protocol Configuration Example
•Automatic Protection Switching Configuration Example
•SONET and SDH Framing Configuration Example
•Layer 2 Protocol Tunneling Topology with a Cisco 7600 and Cisco 7200 Configuration Example
•Cisco 7600 Basic Back-to-Back Configuration Example
•Catalyst 5500 Switch and Cisco 7600 Series Routers in Back-to-Back Topology Configuration Example
•Cisco 7600 and Cisco 7200 in Back-to-Back Topology Configuration Example
Basic Interface Configuration Example
!
interface ATM5/1/0
mtu 9216
no ip address
atm clock INTERNAL
!
interface ATM5/1/0.1 point-to-point
mtu 9216
ip address 70.1.1.1 255.255.0.0
pvc 52/100
!
!
interface ATM5/1/1
mtu 9216
no ip address
atm clock INTERNAL
!
interface ATM5/1/1.1 point-to-point
mtu 9216
ip address 70.2.1.1 255.255.0.0
pvc 53/100
!
!
interface ATM5/1/2
no ip address
atm clock INTERNAL
!
interface ATM5/1/3
no ip address
atm clock INTERNAL
!
MTU Configuration Example
!
interface ATM4/1/0
ip address 192.168.100.13 255.255.255.0
mtu 9216
ip mtu 9188
mpls mtu 9288
atm clock INTERNAL
!
Permanent Virtual Circuit Configuration Example
!
interface ATM5/0/0
no ip address
pvc 1/100
protocol ip 1.1.1.3
protocol ip 20.1.1.1
broadcast
!
!
interface ATM5/0/1
no ip address
!
interface ATM5/1/1
ip address 1.1.1.1 255.255.255.0
load-interval 30
pvc 1/100
protocol ip 1.1.1.3
protocol ip 20.1.1.1
cbr 140000
broadcast
oam-pvc manage
!
pvc 1/101
protocol ip 9.9.9.2
encapsulation aal5ciscoppp Virtual-Template1
!
PVC on a Point-to-Point Subinterface Configuration Example
The following example shows a simple configuration of several PVCs that are configured on point-to-point subinterfaces:
interface ATM3/1/0
no ip address
!
interface ATM3/1/0.1 point-to-point
pvc 4/44 l2transport
mpls l2transport route 22.22.22.22 400
!
!
interface ATM3/1/0.2 point-to-point
pvc 5/55 l2transport
encapsulation aal0
mpls l2transport route 22.22.22.22 500
!
!
interface ATM3/1/0.3 point-to-point
ip address 99.0.0.2 255.0.0.0
pvc 9/99
!
!
interface ATM5/0/0
description flexwan_6_0_0
no ip address
logging event link-status
atm clock INTERNAL
!
interface ATM5/0/0.1 point-to-point
ip address 50.1.1.1 255.255.255.0
pvc 50/11
!
!
interface ATM5/0/0.2 point-to-point
ip address 50.2.2.1 255.255.255.0
pvc 50/12
!
!
interface ATM5/0/0.3 point-to-point
ip address 50.3.3.1 255.255.255.0
pvc 50/13
!
!
interface ATM5/0/0.4 point-to-point
ip address 50.4.4.1 255.255.255.0
pvc 50/14
!
!
interface ATM5/0/0.5 point-to-point
ip address 50.5.5.1 255.255.255.0
pvc 50/15
!
!
interface ATM5/1/0.1 point-to-point
ip address 2.0.0.2 255.255.255.0
!
interface ATM5/1/0.2 point-to-point
ip address 2.0.1.2 255.255.255.0
!
interface ATM5/1/0.3 point-to-point
ip address 39.0.0.1 255.0.0.0
!
PVC on a Multipoint Subinterface Configuration Example
!
interface ATM4/1/0
no ip address
atm clock INTERNAL
!
interface ATM4/1/0.2 multipoint
ip address 1.1.1.1 255.0.0.0
pvc 0/121
protocol ip 1.1.1.23 broadcast
vbr-nrt 2358 2358
encapsulation aal5snap
!
pvc 0/122
protocol ip 1.1.1.24 broadcast
vbr-nrt 2358 2358
encapsulation aal5snap
!
pvc 0/123
protocol ip 1.1.1.25 broadcast
vbr-nrt 2358 2358
encapsulation aal5snap
!
pvc 0/124
protocol ip 1.1.1.26 broadcast
vbr-nrt 2358 2358
encapsulation aal5snap
!
pvc 0/125
protocol ip 1.1.1.27 broadcast
!
...
interface ATM5/1/1
ip address 1.1.1.1 255.255.255.0
load-interval 30
pvc 1/100
protocol ip 1.1.1.3
protocol ip 20.1.1.1
cbr 140000
broadcast
oam-pvc manage
!
pvc 1/101
protocol ip 9.9.9.2
encapsulation aal5ciscoppp Virtual-Template1
!
!
interface ATM5/1/1.200 multipoint
ip address 7.7.7.1 255.255.255.0
bundle bundle
pvc-bundle high 2/100
class-vc high
pvc-bundle med 2/101
class-vc med
pvc-bundle low 2/102
class-vc low
!
!
interface ATM5/1/2
no ip address
!
interface ATM5/1/3
no ip address
!
RFC 1483 Bridging for PVCs Configuration Example
The following shows a simple example of an ATM interface and PVC that have been configured for RFC 1483 bridging with a Fast Ethernet interface:
vlan 30
!
interface FastEthernet7/1
no ip address
duplex full
speed 100
switchport
switchport access vlan 30
switchport mode access
!
interface ATM9/1/0
no ip address
mtu 4096
bandwidth 2000
pvc 0/39
bridge-domain 30
encapsulation aal5snap
!
interface ATM9/1/0.2 point-to-point
ip address 10.10.12.2 255.255.255.0
ip access-group rbe-list in
atm route-bridged ip
no mls ip
pvc 10/200
!
router rip
network 10.0.0.0
network 30.0.0.0
!
RFC 1483 Bridging for PVCs with IEEE 802.1Q Tunneling Configuration Example
The following shows a simple example of an ATM interface that has been configured for RFC 1483 bridging using IEEE 802.1Q tunneling:
interface ATM6/2/0
no ip address
shutdown
atm clock INTERNAL
atm mtu-reject-call
no atm ilmi-keepalive
pvc 2/101
bridge-domain 99 dot1q-tunnel
!
mls qos trust dscp
spanning-tree bpdufilter enable
ATM RFC 1483 Half-Bridging Configuration Example
The following simple example shows an ATM subinterface configured for half-bridging:
!
interface ATM5/1/0.100 multipoint
ip address 192.168.100.14 255.255.0.0
mtu 1500
pvc 10/200
encapsulation aal5snap bridge
!
ATM Routed Bridge Encapsulation Configuration Example
The following simple example shows an ATM subinterface configured for RBE, also known as RFC 1483 half-bridging:
!
interface ATM5/1/0.100 point-to-point
ip address 10.10.10.121 255.255.0.0
mtu 1500
atm route-bridged ip
pvc 100/100
encapsulation aal5snap
!
Precedence-Based Aggregate WRED Configuration Example
The following example shows a precedence-based aggregate WRED configuration:
! Create a policy map named prec-aggr-wred.
!
Router(config)# policy-map prec-aggr-wred
!
! Configure a default class for the policy map.
!
Router(config-pmap)# class class-default
!
! Enable precedence-based (the default setting) aggregate WRED for the default class.
!
Router(config-pmap-c)# random-detect aggregate
!
! Define an aggregate subclass for packets with IP Precedence values of 0-3 and assign the ! WRED profile parameter values for this subclass.
!
Router(config-pmap-c)# random-detect precedence values 0 1 2 3 minimum thresh 10 maximum-thresh 100 mark-prob 10
!
! Define an aggregate subclass for packets with IP Precedence values of 4 and 5 and assign ! the WRED profile parameter values for this subclass.
!
Router(config-pmap-c)# random-detect precedence values 4 5 minimum-thresh 40 maximum-thresh 400 mark-prob 10
!
! Define an aggregate subclass for packets with an IP Precedence value of 6 and assign the ! WRED profile parameter values for this subclass.
!
Router(config-pmap-c)# random-detect precedence values 6 minimum-thresh 60 maximum-thresh 600 mark-prob 10
!
! Define an aggregate subclass for packets with an IP Precedence value of 7 and assign the ! WRED profile parameter values for this subclass.
!
Router(config-pmap-c)# random-detect precedence values 7 minimum-thresh 70 maximum-thresh 700 mark-prob 10
!
! Attach the policy map prec-aggr-wred to the interface.
Note all ATM SPA service policies
! are applied at the atm vc level.
!
Router(config-pmap-c)# interface ATM4/1/0.10 point-to-point
Router(config-subif)# ip address 10.0.0.2 255.255.255.0
Router(config-subif)# pvc 10/110
Router(config-subif)# service policy output prec-aggr-wred
DSCP-Based Aggregate WRED Configuration Example
The following example shows a DSCP-based aggregate WRED configuration:
! Create a policy map named dscp-aggr-wred.
!
Router(config)# policy-map dscp-aggr-wred
!
! Configure a default class for the policy map.
!
Router(config-pmap)# class class-default
!
! Enable dscp-based aggregate WRED for the default class and assign the
! default WRED profile parameter values to be used for all subclasses that have not been
! specifically configured..
!
Router(config-pmap-c)# random-detect dscp-based aggregate minimum-thresh 1 maximum-thresh 10 mark-prob 10
!
! Define an aggregate subclass for packets with DSCP values of 0-7 and assign the WRED
! profile parameter values for this subclass
!
Router(config-pmap-c)# random-detect dscp values 0 1 2 3 4 5 6 7 minimum-thresh 10 maximum-thresh 20 mark-prob 10
!
! Define an aggregate subclass for packets with DSCP values of 8-11 and assign the WRED
! profile parameter values for this subclass.
!
Router(config-pmap-c)# random-detect dscp values 8 9 10 11 minimum-thresh 10 maximum-thresh 40 mark-prob 10
!
! Attach the policy map dscp-aggr-wred to the interface.
Note all ATM SPA service policies
! are applied at the atm vc level.
!
Router(config)# interface ATM4/1/0.11 point-to-point
Router(config-subif)# ip address 10.0.0.2 255.255.255.0
Router(config-subif) pvc 11/101
Router(config-subif)# service policy output dscp-aggr-wred
Switched Virtual Circuits Configuration Example
interface ATM4/0/2
ip address 10.23.33.2 255.255.255.0
atm clock INTERNAL
atm pvp 244
atm esi-address 111111111111.11
pvc 0/5 qsaal
!
pvc 0/16 ilmi
!
!
interface ATM4/0/2.1 multipoint
ip address 10.20.0.2 255.0.0.0
atm esi-address 333333333333.33
!
svc nsap 47.009181000000001011B8C601.222222222222.22
protocol ip 10.20.0.1
ubr 1000
!
!
interface ATM4/0/2.2 multipoint
ip address 10.13.3.1 255.255.255.0
atm esi-address 510211111111.11
!
svc nsap 47.009181000000001011B8C601.410233333333.33
protocol ip 10.13.3.3
!
interface ATM4/0/2.3 multipoint
svc SVC1 nsap 47.009181000000BBBBBB000001.222222222222.22
protocol ip 33.33.33.1
broadcast
encapsulation aal5snap
Traffic Parameters for PVCs or SVCs Configuration Example
!
interface ATM5/1/1.100 point-to-point
ip address 10.1.1.1 255.255.255.0
load-interval 30
pvc 1/100
protocol ip 1.1.1.3
protocol ip 20.1.1.1
cbr 100
broadcast
!
!
interface ATM5/1/1.110 point-to-point
ip address 10.2.2.2 255.255.255.0
pvc 1/110
ubr 1000
!
!
interface ATM5/1/1.120 point-to-point
ip address 10.3.3.3 255.255.255.0
no ip directed-broadcast
pvc 1/120
vbr-nrt 50000 50000
encapsulation aal5snap
!
!
interface ATM5/1/1.130 point-to-point
ip address 10.4.4.4 255.255.255.0
pvc 1/130
vbr-rt 445 445
encapsulation aal5snap
!
!
interface ATM5/1/1.140 point-to-point
ip address 10.5.5.5 255.255.255.0
atm arp-server nsap 47.00918100000000107B2B4B01.111155550000.00
atm esi-address 111155550001.00
!
svc SVC00 nsap 47.00918100000000107B2B4B01.222255550001.00
protocol ip 10.5.5.6 broadcast
oam-svc manage
encapsulation aal5mux ip
ubr 1000
!
Virtual Circuit Classes Configuration Example
vc-class atm high-class
ilmi manage
oam-pvc manage 5
oam retry 10 7 3
!
vc-class atm low-class
!
interface ATM4/1/0
no ip address
class-int high-class
atm ilmi-pvc-discovery subinterface
pvc 0/5 qsaal
!
pvc 0/16 ilmi
!
!
interface ATM4/1/0.1 multipoint
pvc 1/110
protocol 10.10.10.14
!
interface ATM4/1/1
ip address 10.10.11.2 255.255.255.0
class-int low-class
atm uni-version 4.0
atm pvp 1
atm esi-address AAAAAAAAAAAA.AA
interface ATM4/1/1.2 multipoint
pvc 2/100
protocol ip 10.10.11.1
!
Virtual Circuit Bundles Configuration Example
!
interface ATM5/1/1
ip address 1.1.1.1 255.255.255.0
load-interval 30
pvc 1/100
protocol ip 1.1.1.3
protocol ip 20.1.1.1
cbr 140000
broadcast
oam-pvc manage
!
pvc 1/101
protocol ip 9.9.9.2
encapsulation aal5ciscoppp Virtual-Template1
!
!
interface ATM5/1/1.200 multipoint
ip address 7.7.7.1 255.255.255.0
bundle atm-bundle
pvc-bundle high 2/100
class-vc high
pvc-bundle med 2/101
class-vc med
pvc-bundle low 2/102
class-vc low
!
Link Fragmentation and Interleaving with Virtual Templates Configuration Example
The following simple example shows a sample LFI configuration using a virtual template interface:
!
vlan internal allocation policy ascending
vlan access-log ratelimit 2000
!
class-map match-all prec4
match ip precedence 4
class-map match-all prec5
match ip precedence 5
class-map match-all prec6
match ip precedence 6
class-map match-all prec7
match ip precedence 7
class-map match-all prec0
match ip precedence 0
class-map match-all prec1
match ip precedence 1
class-map match-all prec2
match ip precedence 2
class-map match-all dscp2
match dscp 2
class-map match-all prec3
match ip precedence 3
class-map match-all prec8
match precedence 0 2 4 6
class-map match-any all
class-map match-all any
match any
!
!
policy-map pmap1
class prec1
bandwidth percent 10
class prec2
police 100000000 3125000 3125000 conform-action transmit exceed-action drop
priority
!
!
!
interface ATM2/1/0
no ip address
atm clock INTERNAL
!
interface ATM2/1/0.1 point-to-point
pvc 0/100
encapsulation aal5snap
protocol ppp Virtual-Template1
!
!
interface ATM2/1/0.1000 point-to-point
pvc 1/1000
encapsulation aal5ciscoppp Virtual-Template2
!
!
interface ATM2/1/0.1001 point-to-point
pvc 1/1001
protocol ip 10.10.11.12
encapsulation aal5ciscoppp Virtual-Template3
!
interface ATM2/1/1
no ip address
shutdown
!
interface ATM2/1/2
no ip address
shutdown
!
interface ATM2/1/3
no ip address
!
interface Virtual-Template1
bandwidth 100
ip address 10.34.0.2 255.255.255.0
no keepalive
ppp chap hostname north-21
ppp multilink
ppp multilink fragment-delay 5
ppp multilink interleave
multilink max-fragments 16
service-policy output pmap1
!
interface Virtual-Template2
ip address 10.36.0.2 255.255.255.0
no keepalive
ppp chap hostname north-22
ppp multilink
ppp multilink fragment-delay 5
ppp multilink interleave
service-policy output pmap1
!
interface Virtual-Template3
ppp chap hostname north-23
ppp multilink
ppp multilink fragment-delay 5
ppp multilink interleave
service-policy output pmap1
!
interface Vlan1
no ip address
shutdown
!
Distributed Compressed Real-Time Protocol Configuration Example
!
interface ATM5/1/0.200 point-to-point
pvc 10/300
encapsulation aal5mux ppp Virtual-Template200
!
...
!
interface Virtual-Template200
bandwidth 2000
ip address 10.1.200.2 255.255.255.0
ip rcp header-compression passive
ip tcp header-compression passive
ppp chap hostname template200
ppp multilink
ppp multilink fragment-delay 8
ppp multilink interleave
ip rtp header-compression passive
ip tcp compression-connections 64
!
Automatic Protection Switching Configuration Example
!
interface ATM4/0/0
description working
ip address 10.5.5.1 255.255.255.0
no shutdown
aps group 1
aps working 1
pvc 1/100
protocol ip 10.5.5.2
!
interface ATM4/0/1
description protect
ip address 10.5.5.1 255.255.255.0
aps group 1
aps revert 2
aps protect 0 10.7.7.7
pvc 1/100
protocol ip 10.5.5.2
!
interface Loopback1
ip address 10.7.7.7 255.255.255.0
SONET and SDH Framing Configuration Example
!
interface ATM2/0/0
description Example of SONET framing-"atm framing sonet" is default and doesn't appear
ip address 10.16.2.2 255.255.255.0
logging event link-status
atm sonet report all
atm sonet threshold sd-ber 3
atm sonet threshold sf-ber 6
atm sonet overhead c2 0x00
!
interface ATM2/0/1
description Example of SDH framing-"atm framing sdh" appears in configuration
ip address 10.16.3.3 255.255.255.0
logging event link-status
atm framing sdh
atm sonet report all
atm sonet overhead c2 0x00
!
Layer 2 Protocol Tunneling Topology with a Cisco 7600, Catalyst 5500, and Catalyst 6500 Configuration Example
Figure 7-7 shows one sample network topology in which data packets are sent between a Catalyst 6500 switch and a Cisco 7600 series router.
Figure 7-7 Catalyst 5500 Switch, 6500 Switch, and Cisco 7600 Series Router in an L2PT Topology
As shown in Figure 7-7, Layer 2 Protocol Tunneling (L2PT) is configured at the Cisco 7600 ATM 6/1/0 interface and also at the Catalyst 6500 switch Gig 2/1 interface.
PVST packets are sent from the Catalyst 5500 switch to the Cisco 7600 series router. The Cisco 7600 router transports those BPDUs by way of L2PT and sends them to the Catalyst 6500 switch. Those BPDUs are decapsulated and restored before sending the packets out to the customer network.
The Cisco 7600 router and the Catalyst 6500 switch are provider edge (PE) devices and the rest are customer edge (CE) devices.
ATM Configuration Example
Any traffic coming in must be sent via a dot1q-tunnel. If the PE VLAN is 200 and the CE VLAN is 100, you have the following configuration:
Router(config)#
interface atm 6/1/0
Router(config-if)#
pvc 6/200
Router(config-if-atm-vc)#
bridge-domain 200 dot1q-tunnel ignore-bpdu-pid pvst-tlv 100
Ethernet Configuration Example
An example of the Ethernet configuration follows:
Router(config)#
interface gig2/1
Router(config-if)#
switchport
Router(config-if)#
switchport access vlan 200
Router(config-if)#switchport mode dot1q-tunnel
Router(config-if)#
l2protocol-tunnel
CE VLAN 100 is what is used at the customer sites. The Catalyst 5500 switch sends the IEEE BPDU in data format. The Cisco 7600 router receives the BPDU and first converts it to PVST+ format. Then the destination address (DA) MAC of the frame is changed to the protocol tunnel MAC address and sent out into the Layer 2 cloud.
At the other end, when the frame leaves the Gig 2/1 interface, the DA MAC is changed back to the PVST+ DA MAC and the PVST+ BPDU is sent to the CPE device.
Layer 2 Protocol Tunneling Topology with a Cisco 7600 and Cisco 7200 Configuration Example
In this example, a Cisco 7600 series router needs to communicate with a Cisco 7200 series router.
Figure 7-8 Cisco 7600 and Cisco 7200 Routers in an L2PT Topology
PE Configuration
On the PE routers, the configuration appears as follows:
!On PE 1
interface ATM2/0/0
no ip address
atm mtu-reject-call
pvc 7/101
bridge-domain 200 dot1q-tunnel
!
end
!On PE 2
interface ATM3/0/0
no ip address
pvc 2/101
bridge-domain 200 dot1q-tunnel pvst-tlv 100
!
end
Cisco 7600 CE Configuration
The configuration for the Cisco 7600 CE 1 router would be as follows:
!On CE 1
interface ATM1/1/0
no ip address
atm mtu-reject-call
pvc 7/101
bridge-domain 101
!
end
Cisco 7200 CE Configuration
The configuration for the Cisco 7200 CE 2 router would be as follows:
!On CE 2
interface ATM4/0
no ip address
no atm ilmi-keepalive
pvc 2/101
!
bridge-group 101
end
Data Transmission Sequence from the Cisco 7200 CE to the Cisco 7600 CE
With the configurations and topologies shown in these examples, the data transmission sequence from the Cisco 7200 CE to the Cisco 7600 CE is as follows:
1. The Cisco 7200 CE 2 router sends BPDUs without the MAC header in RFC 1483 format.
2. The Cisco 7600 PE router receives the packets and then translates the IEEE BPDU into PVST+ BPDU format.
3. VLAN 100 is inserted into the PVST+ BPDU.
4. The frame's destination address (DA) MAC value is rewritten to use the protocol tunnel DA MAC and is sent out into the ATM network cloud.
5. The L2PT BPDU must go out of the PE 1 ATM 2/0/0 interface. The DA MAC is restored to the PVST+ DA MAC.
6. The PVST+ BPDU is sent to the Cisco 7600 CE 1 router.
Cisco 7600 Basic Back-to-Back Configuration Example
Figure 7-9 shows an example of a basic back-to-back configuration.
Figure 7-9 Cisco 7600 Routers in Basic Back-to-Back Topology
The PDUs exchanged are PVST+ BPDUs. The PVST+ BPDUs are sent using a PID of 0x00-07. The configuration is set as follows:
Router(config)#
interface atm 2/1/0
Router(config-if)#
pvc 2/202
Router(config-if-atm-vc)#
bridge-domain 101
Catalyst 5500 Switch and Cisco 7600 Series Routers in Back-to-Back Topology Configuration Example
Another sample topology is a simple back-to-back setup, which tests basic Catalyst 5500 and Cisco 7600 interoperability.
Figure 7-10 Catalyst 5500 Switch and Cisco 7600 Routers in Back-to-Back Topology
When connected to a device that sends and receives IEEE BPDUs in data format (PID 0x00-07) such as the Catalyst 5000's ATM module, the configuration must be similar to the following:
Router(config)#
interface atm 2/1/0
Router(config-if)#
pvc 2/202
Router(config-if-atm-vc)#
bridge-domain 101 ignore-bpdu-pid pvst-tlv 101
The Cisco 7600 router translates its outgoing PVST+ BPDUs into IEEE BPDUs. Because the ignore-bpdu-pid keyword is also enabled, the BPDU uses a PID of 0x00-07, which is exactly what the Catalyst 5500 switch requires.
Cisco 7600 and Cisco 7200 in Back-to-Back Topology Configuration Example
When connecting to a device that is completely RFC 1483 compliant, in which the IEEE BPDUs are sent using a PID of 0x00-0E, you must use the new ignore-bpdu-pid keyword in the bridge-domain command.
Figure 7-11 Cisco 7600 Router Series and Cisco 7200 Router Series in Back-to-Back Topology
For example, when a Cisco 7600 series router is connected to a Cisco 7200 series router, the configuration would be as follows:
Router(config)#
interface atm 2/1/0
Router(config-if)#
pvc 2/202
Router(config-if-atm-vc)#
bridge-domain 101 pvst-tlv 101
Note In this configuration scenario, the CE's VLAN number must be identical to the bridge-domain VLAN number.
An example of the Ethernet configuration follows:
Router(config)#
interface gig2/1
Router(config-if)#
switchport
Router(config-if)#
switchport access vlan 200
Router(config-if)#switchport mode dot1q-tunnel
Router(config-if)#
l2protocol-tunnel