Central Office/Exchange Equipment
This section discusses the configurations for the two pieces of CO/exchange gear in the DSL network—the Cisco 6000 series IP DSL Switch and the Cisco 6400 UAC.
IP DSL Switch/NI-2
The NI-2 Cisco IOS Software is based on the Catalyst 8500 (also known as the LightStream 1010) code, with added extensions for DSL. The IOS code supports ATM services such as ATM QoS and traffic management, PVCs and soft-PVCs, and ILMI and OAM cell support.
After the initial configuration, you can either continue to manage the DSLAM/IP DSL Switch with the Cisco IOS Software command-line interface (CLI) or use the Cisco DSL Manager (CDM) graphical user interface (GUI) software. Even if you choose to manage the device with CDM (this is covered in Chapter 7, "Cisco DSL Manager (CDM)"), you must still use a few Cisco IOS Software commands to prepare the device for CDM.
Basic Setup Commands
To start setting up the NI-2, you can access the CLI by connecting a terminal directly to the console port on the NI-2 card or by Telnetting to the management port if an IP address has been configured on the NI-2 Ethernet interface. Because the NI-2 runs a specific version of Cisco IOS Software, many commands are unique to the DSL service environment. The software image itself is designated with the letters DA. The D indicates that this is a Cisco IOS Software release for the DSL environment, and the A indicates that it is specifically for the NI-2. (As you will learn in the section "Aggregator/Concentrator: Cisco 6400," other specific software versions also start with D for DSL but have a different second letter.)
The System Configuration dialog and the CLI use the interface numbering scheme shown in Figure 6-5.
)
Figure
6-5 Cisco 6160 Interfaces
Interfaces whose names begin with ATM0 (ATM0/0, ATM0/1, and so on) are NI-2 card WAN interfaces. ATM0/0 is the ATM switch's interface with the processor. There is no need to configure ATM0/0 unless you plan to use in-band management. ATM0/1 is the trunk port, also called the upstream or network trunk. ATM0/2 and ATM0/3 (if present) are subtending interfaces.
Interfaces whose names begin with ATM1, including all the higher numbers after the ATM- designator, are xTU-C (line card) interfaces. The range of line cards is ATM1 through ATM6 on the compact 6015, ATM1 through ATM30 on the international 6260, or ATM1 through ATM32 on the North American 6160. ATM10 and ATM11, which would indicate the NI-2 slots, are omitted in the software configuration on the two larger IP DSL Switches, although these are labeled as slots 10 and 11 on the chassis itself.
Ethernet0/0 is the interface for the LAN that connects the Cisco IP DSL Switch to its management system.
For individual line card ports, the number before the slash indicates the slot number. The number after the slash indicates the interface or port number. For example, ATM6/4 is port 4 in slot 6.
The following steps show you how to configure the NI-2 for basic operations:
Step 1 Specify software codes. You should specify the source and filename of the configuration that will be used to boot the NI-2. Use the global configuration mode command boot system flash: path filename to specify the boot file. You can use the file system in Flash memory to copy files and troubleshoot configuration problems. Use the privileged EXEC command dir flash: to display the contents of Flash memory. This process might take a few minutes while Flash memory is being initialized.
DSLAM#dir flash: Directory of flash:/ 2 -rw- 4883532 Jan 01 2000 00:02:46 NI-2-dsl-mz.120-5.DA1 3 -rw- 5396464 Jan 02 2000 02:04:08 NI-2-dsl-mx.flexi.aluia 4 -rw- 345324 Jan 02 2000 02:06:13 flexd.bin.aluia 15990784 bytes total (413568 bytes free)Step 2 Set the IP address on the primary Ethernet interface. You should set the IP address, and the subnet mask if you won't use the default, on the interface Eth 0/0. Use the interface configuration mode command ip address XXX.XXX.XXX.XXX yyy.yyy.yyy.yyy, where X represents the IP address and Y represents the subnet mask.
Step 3 Set the passwords. At a minimum, you will set three passwords:
Console password—Set the console password using the standard Cisco IOS Software configuration command password.
Telnet password—At the privileged EXEC mode prompt, enter the following commands:
NI-2#config terminal NI-2 (config)#line vty 0 4 NI-2 (config- line)#password <TELNET PASSWORD> NI-2 (config- line)#loginExit, and then test by Telnetting into the device.
Privileged EXEC password, also erroneously but popularly called the enable password—You set the privileged EXEC password using the standard Cisco IOS Software configuration command enable secret or enable password.
Step 4 Set the time, date, and host name. Although it isn't absolutely required, you can set several system parameters as part of the initial system configuration.
Step 5 Set the clocking options. Each port has a transmit clock and derives its receive clock from the receive data. You can configure transmit clocking for each port in one of the following ways:
Network derived—Transmit clocking is derived from the highest-priority configured source, either from the internal clock (the default) or the public network.
Loop-timed—Transmit clocking is derived from the receive clock source. The IP DSL Switch receives derived clocking, along with data, from a specified interface. Because the port providing the network clock source could fail, Cisco IOS Software lets you configure additional interfaces as clock sources with priorities 1 to 4.
If the network clock source interface stops responding, the software switches to the next-highest-configured priority network clock source.
NOTE
By default, the network clock is configured as nonrevertive. This is because the industry standard is to prefer a stable, if less-accurate, clock source over an unstable, even if more-accurate, clock source. Virtually every service provider's policy is to verify original clock source stability for a set period of several hours before reverting manually to that original source, while depending on the secondary, stable clock source in the interim.
The algorithm to switch to the highest-priority best clock runs only if you configure the network-clock-select command as revertive.
To configure the network clocking priorities and sources, use the following command in global configuration mode:
network-clock-select {priority} {bits} {atm} {system | card/port} [revertive]The following example configures interface 0/0 as the highest-priority clock source to receive the network clocking, interface 0/2 as the second-highest priority, and interface 0/1 as the third-highest priority:
NI-2#config term NI-2(config)#network-clock-select 1 atm 0/0 NI-2(config)#network-clock-select 2 atm 0/2 NI-2(config)#network-clock-select 3 atm 0/1The following example shows how to configure the network clock to revert to the highest-priority clock source after a failure:
NI-2(config)#network-clock-select revertiveTo configure the location from which an interface receives its transmit clocking, perform these tasks, beginning in global configuration mode:
Select the interface to be configured:
interface atm card/portConfigure the interface network clock source:
clock source {free-running | loop-timed | network-derived}Network-derived means the highest-priority clock that is both configured and functional.
The following example configures ATM interface 0/1 to receive its transmit clocking from a network-derived source:
NI-2(config)#interface atm 0/1 NI-2(config-if)#clock source network-derivedAny module in a DSLAM chassis that can receive and distribute a network timing signal can propagate that signal to any similarly capable module in the chassis. The following entities can receive and distribute a Primary Reference Source (PRS) for synchronization:
A Building Integrated Timing Supply (BITS) clock through the I/O card
An OC-3/STM1 in an IP DSL Switch chassis
A DS3/E3 module in an IP DSL Switch chassis that derives the clock from the trunk interface
The two trunk ports can propagate a clocking signal in either direction.
If you issue the network-clock-select command with the appropriate parameters, you can define any particular port in an IP DSL Switch chassis (subject to the previously discussed limitations) to serve as the clock source for the entire chassis or for other devices in the networking environment.
You can also use the network-clock-select command to designate a particular port in an IP DSL Switch chassis to serve as a master clock source for distributing a single clocking signal throughout the chassis or to other network devices. You can distribute this reference signal wherever the network needs to globally synchronize the flow of constant bit rate (CBR) data.
Step 6 Set the subtending numbers. If your DSL network will use subtending (subtending is discussed in Chapter 4), how can the network administrator guarantee adequate bandwidth and fairness of access for all subscribers in a subtended implementation?
The answer lies in leveraging the scheduler process on each IP DSL Switch that subtends another IP DSL Switch. (Incidentally, in a regular subtended tree configuration, there is automatic recovery from a failure of any node. In other words, a single failed node in the subtended family does not disrupt user traffic in the other, working IP DSL Switches.)
To guarantee that all subtended subscribers have equal access to the trunk port, the IP DSL Switch uses 13 numbered queues that are accessed in round-robin fashion. This approach keys off the subtend-id, which must be set in each subtended IP DSL Switch. This process is shown in Figure 6-6 and is
described in more detail in the following list:
Each IP DSL Switch has 13 queues, starting with 0, which services the local (onboard) DSL subscribers for each IP DSL Switch.
When traffic comes from a subtended trunk, the General Flow Control (GFC) number determines the queue in which the traffic will be put.
The GFC number for subtended nodes is set equal to the subtend-id plus 3.
In Figure 6-6, the last node on the subtend tree has a subtend-id of 2. Local DSL subscriber traffic populates queue 0.
When that traffic is transmitted on the subtended trunk (0/1), it is assigned a GFC of 5 (subtend-id + 3).
In subtend node 1, that traffic populates queue 5. Local DSL subscriber traffic populates queue 0. The node services these two queues in a round-robin fashion.
When subtend node 1 traffic from queue 0 is sent up the subtended trunk, it is assigned GFC = 4 (subtend-id + 3) and populates queue 4. Traffic from queue 5 retains GFC = 5 and populates queue 5.
In the top-level node, local DSL subscriber traffic populates queue 0.
The top subtend node services queues 0, 4, and 5 in a round-robin fashion, thereby giving all DSL subscribers equal access to the network trunk.
You can set the subtend node identifier using the following global command:
subtend-id node#where node# is the node for which the command sets the subtend node identifier. The range is 0 to 12.
In this example, the command sets the DSL subtend node identifier to node 12:
NI-2#conf t NI-2 (config)subtend-id 12Step 7 Configure Simple Network Management Protocol (SNMP) for CDM use or to direct SNMP traps to another system. Enter the following commands while in privileged EXEC mode:
NI-2#config terminal NI-2 (config)#snmp-server community <PUBLIC> ro NI-2 (config)#snmp-server community <PRIVATE> rw NI-2 (config)#snmp-server host <CEMF Server IP Address> traps version 2c public NI-2 (config)#snmp-server enable traps
Figure 6-6 Subtending Queues
Step 8 After the basic NI-2 setup, you should verify that the NI-2 has autorecognized the line cards. Here is how that autodiscovery works:
The NI-2 autodiscovers all xTU-Cs (line cards) when they are installed. First the NI-2 verifies that the card is valid for that type of chassis. Second, for all but the Flexi card, the NI-2 compares the line card's installed software image to the particular software image that the NI-2 itself contains in its configuration. If the line card's installed image does not match the NI-2's image for that card type, the NI-2 automatically updates the line card with the software image that the NI-2 has available.
)
Figure
6-6 In the case of the Flexi card, the NI-2 can complete only the first step. As you saw in Chapter 4, the Flexi card offers connectivity for either the legacy Carrierless Amplitude Phase (CAP) modulation or the standardized DMT modulations (both full-rate and half-rate DMT). You must manually set the card to either CAP or DMT after initial recognition by the NI-2. (The Flexi card itself autorecognizes the difference between DMT2 and G.Lite coming from the CPE after the Flexi has been configured for DMT.) The NI-2 then completes its analysis of the Flexi line card's onboard image version and updates it as necessary. Here is the manual command format, starting in global configuration mode:
slot slot# cardtype
slot# is the slot number. For the 6160 IP DSL Switch, the range is 1 to 32. For the 6260 device, the range is 1 to 30. For the 6015, the range is 1 to 6.
cardtype is the modulation type for which you want to configure the slot.
Here's an example:
6160-94(config)#slot X atuc-4flexi{cap | dmt}
You cannot simply physically remove a line card from the chassis without changing the NI-2's configuration. To remove a line card from the NI-2's configuration, use the standard Cisco no option of the command for all card types, like this:
6160-94(config)#no slot X atuc-1-4dmt
At this point, after completing the previous eight steps (or the standard Cisco IOS Software startup configuration menu), with or without the optional subtending configurations, you could begin using the GUI CDM program. CDM lets you manage the IP DSL Switch, including provisioning the individual connections.
Continuing with Cisco IOS Software configuration of the NI-2, the next section describes configuring the NI-2 for redundant operations.
Redundancy Commands
Starting with Cisco IOS Software version 12.1(6)DA, NI-2 cards can be configured for redundancy in the IP DSL Switch. Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) NI-2s (OC-3 or STM1) have redundant physical links, and Automatic Protection Switching (APS) is in place. APS in the modern telecommunication equipment world is virtually hitless, because most modern fiber-equipped devices switch traffic in much less time than the APS-defined maximum 50 milliseconds. For instance, the NI-2 switches traffic in about 8 to 10 milliseconds. Because the human ear rarely detects gaps of 9 milliseconds or less in speech, even voice traffic is considered hitless. For data traffic, such a small interval is easily overcome by buffering and automatic retransmission if necessary.
For coaxial NI-2 cards, such as the DS3 and E3, if a physical link fails (the cable is cut), there is no switchover. Currently no redundant DS3/E3 physical links exist, so the NI-2 cannot overcome coaxial link failures. If a coaxial NI-2 card itself fails, there is protection, because the standby card takes activity automatically and takes over the coaxial ports on the IP DSL Switch I/O card on the backplane.
In cases of fiber- and coaxially-connected NI-2 failure, the secondary NI-2 assumes the configuration of the primary NI-2. All the ATM information stays the same, with the exception of the dynamically mapping switched virtual circuits (SVCs). These have to be reconfigured in the event of NI-2 failure.
The Ethernet IP address stays the same, but the MAC address might have to be reacquired through Reverse Address Resolution Protocol (RARP), depending on the degree of prior synchronization between the two NI-2 cards. Because the MAC address is stored on the I/O card, it can be shared between the NI-2s.
You must load the same redundancy-capable IOS image in both NI-2 cards. Do not install an NI-2 with IOS earlier than 12.1(2)DA in an IP DSL Switch with another NI-2 already in service. (A service interruption will result.)
APS-Related CLI Commands
The APS CLI commands include show APS and show controllers.
The show APS command displays APS state information.
The show controllers command is a classic IOS command that provides information on both the active and inactive OC-3/STM1 interfaces. You can use this command to determine which OC-3/STM1 NI-2 is online and which OC-3/STM1 interface is active. Following are seven examples of this command's output:
6160-1#show controller atm 0/1
IF Name: ATM0/1 Chip Base Address: B3809000
Port type: OC3 Port rate: 155000 kbps Port medium: SM Fiber
local peer
(working) (protection)
ACTIVE INACTIVE
--------------- ---------------
Port status Good Signal Good Signal
Loopback None None
Flags 0x8300 0x8308
TX clock source loop-timed loop-timed
Framing mode sts-3c sts-3c
Cell payload scrambling On On
Sts-stream scrambling On On
TX Led: Off Off
RX Led: Off Off
TST Led: Off Off
The output of the command show controller atm0/1 reports that the secondary NI-2 (slot 11, protection) is online. The primary NI-2 (slot 10) is installed, functional, and in standby mode. The OC-3 datastream received by the secondary NI-2 port 0/1 is the datastream being processed by the system (active).
Controller terminology includes the following:
Local—This is always the online NI-2, either slot 10 or slot 11.
Peer—This is always the standby card, either slot 10 or slot 11.
Working—This is always the card in slot 10. Working is an APS term that is the same as the term primary in redundant NI-2 systems.
Protection—This is the same as secondary in NI-2 systems. It is always slot 11.
Active—The OC-3/STM1 receiving datastream on this port is the one used by the system.
Inactive—The OC-3/STM1 receiving datastream on this port is not being used as the active traffic source.
Following is different output for the show controller atm0/1 command:
6160-1#show controller atm0/1
IF Name: ATM0/1 Chip Base Address: B3809000
Port type: OC3 Port rate: 155000 kbps Port medium: SM Fiber
local peer
(protection) (working)
ACTIVE INACTIVE
--------------- -------------
Port status Good Signal Good Signal
Loopback None None
Flags 0x8300 0x8308
TX clock source loop-timed loop-timed
Framing mode sts-3c sts-3c
Cell payload scrambling On On
Sts-stream scrambling On On
TX Led: Off Off
RX Led: Off Off
TST Led: Off Off
In this case, the output from the command show controller atm0/1 reports that the secondary NI-2 (slot 11, protection) is online. The primary NI-2 (slot 10) is installed, functional, and in standby mode. The OC-3 datastream received by the secondary NI-2 port 0/1 is the datastream being processed by the system (active).
Here is the third example of the command show controller atm0/1:
6160-1#show controller atm 0/1
IF Name: ATM0/1 Chip Base Address: B3809000
Port type: OC3 Port rate: 155000 kbps Port medium: SM Fiber
Alarms: Source: ATM0/1 protect
Severity: CRITICAL Description: 12 Loss of Signal
local peer
(working) (protection)
ACTIVE INACTIVE
--------------- ---------------
Port status Good Signal SECTION LOS
Loopback None None
Flags 0x8300 0x8308
TX clock source loop-timed loop-timed
Framing mode sts-3c sts-3c
Cell payload scrambling On On
Sts-stream scrambling On On
TX Led: Off Off
RX Led: Off On
TST Led: Off Off
In this case, the output indicates a loss of signal (LOS) on the protect (secondary) NI-2 ATM0/1 port. The primary NI-2 (slot 10) is online, and the active OC-3 datastream is on slot 10.
Here is the fourth example of the command show controller atm0/1:
6160-1#show controller atm0/1
IF Name: ATM0/1 Chip Base Address: B3809000
Port type: OC3 Port rate: 155000 kbps Port medium: SM Fiber
Alarms:
Source: ATM0/1 protect
Severity: CRITICAL
Description: 12 Loss of Signal
local peer
(protection) (working)
INACTIVE ACTIVE
--------------- ---------------
Port status SECTION LOS Good Signal
Loopback None None
Flags 0x8300 0x8308
TX clock source loop-timed loop-timed
Framing mode sts-3c sts-3c
Cell payload scrambling On On
Sts-stream scrambling On On
TX Led: Off Off
RX Led: On Off
TST Led: Off Off
In this case, the output from show controller atm0/1 reports a LOS on the protect (secondary) NI-2 0/1 port (slot 11), but the secondary NI-2 is online. The OC-3 datastream received by the NI-2 in slot 10 is being processed by the system (NI-2 in slot 11).
Here is the fifth of the seven examples of the command show controller atm0/1:
6160-1#show controller atm0/1
IF Name: ATM0/1 Chip Base Address: B3809000
Port type: OC3 Port rate: 155000 kbps Port medium: SM Fiber
local peer
(working) (protection)
ACTIVE INACTIVE
--------------- ---------------
Port status Good Signal Not available
Loopback None Not available
Flags 0x8300 Not available
TX clock source loop-timed Not available
Framing mode sts-3c Not available
Cell payload scrambling On Not available
Sts-stream scrambling On Not available
TX Led: Off Not available
RX Led: Off Not available
TST Led: Off Not available
The Not available status for peer (protection) in the output indicates that the standby NI-2 in slot 11 has not booted to a standby state. This is a normal status after switching from active to standby. Not available is reported for approximately 60 seconds after switchover, while the previously online card restarts.
Following is the sixth example of show controller atm0/1. In this case, it is for a coaxial (DS3) NI-2 variant:
6160-1#show controller atm0/1 IF Name: ATM0/1, Chip Base Address: B3809000 Port type: DS3 Port rate: 45000 kbps Port medium: Coax Loopback:None Flags:8000 Port status: LOS Source: ATM0/1 Severity: CRITICAL Description: 6 LOS Detected TX Led: Off RX Led: On TST Led: Off TX clock source: network-derived DS3 Framing Mode: m23 plcp FERF on AIS is on FERF on LCD is on (n/a in PLCP mode) FERF on RED is on FERF on OOF is on FERF on LOS is on LBO: <= 225'
The output shows a LOS on the DS3 trunk port 0/1. The status is reported by the online NI-2.
Finally, the following is the last output example for show controller atm0/1, following the command redundancy switch-activity. The online NI-2 reboots but does not complete the restart sequence, as evidenced by the following output:
Cisco Internetwork Operating System Software IOS (tm) NI2 Software (NI2-DSL-M), Experimental Version 12.1(20000906:224310) Copyright (c) 1986-2000 by cisco Systems, Inc. Compiled Thu 21-Sep-00 14:54 by satrao Image text-base: 0x800082B8, data-base: 0x80BD6000 *** This is the STANDBY unit. Initialization is being held. ***
This standby NI-2 completes its restart sequence and becomes the online unit. After the statement Initialization is being held is sent, the console port is inactive.
Secondary Unit Sync Commands
This section describes different levels of synchronization between the primary and secondary NI-2 cards and the commands to set up the synchronization. The NI-2 cards have different levels of memory and therefore different levels of synchronization of the memory contents. As with almost all Cisco IOS Software-based devices, there is bootflash memory, Flash memory, NVRAM memory, and the running configuration itself, which might not be saved in a particular moment in time.
For optimal redundancy preparedness, you should ensure that both NI-2s have the same running configuration and startup configuration. These two files are automatically synchronized between the two NI-2s when both NI cards are loaded with a redundancy-capable version of IOS, 12.1(6) or later (you should have identical IOS versions loaded on both cards). However, auto-sync can be enabled only when Flash itself is in sync. You must manually sync Flash before enabling auto-sync, because auto-sync flash is not enabled by default.
Here is the command to synchronize Flash, along with its related command to synchronize bootflash:
NI-2(config)#auto-sync flash NI-2(config)#auto-sync bootflash
After you enter at least the first command, if not both, the configurations are automatically synchronized on an ongoing basis by default.
For verification, you can also directly enter the following commands to enable automatic synchronization:
NI-2(config)#auto-sync running-config NI-2(config)#auto-sync config
You can also directly create synchronization for each type of memory on the NI-2 cards with the following commands:
The NI-2#secondary sync flash command mirrors Flash on the secondary NI-2 by copying the contents of the primary NI-2 Flash to the secondary NI-2 Flash. This function is disabled by default.
The NI-2#secondary sync bootflash command provides the same function as sync flash, but for bootflash. This function is disabled by default.
Verifying Memory Content
The following commands involve checking memory contents (don't overlook the ending colons!) from the privileged EXEC (enable) prompt.
The following two commands allow a quick comparison of which files are in Flash memory on the primary and secondary NI-2s:
NI-2#dir flash: NI-2#dir secondary-flash:
The next two commands allow a quick comparison of the files in bootflash on the primary and secondary NI-2:
NI-2#dir bootflash: NI-2#dir secondary-bootflash:
The next two commands allow a quick comparison of primary and secondary NVRAM, which is the simplest way to verify synchronization of the two NI-2 cards' configurations:
NI-2#dir nvram: NI-2#dir secondary-nvram:
You can gain access to each NI-2 independently, which results in two different NI-2s unless auto-sync mode is in effect. You might use the following command if one of the NI-2s is being prepared for an upgrade or for use in another Cisco 6000 series IP DSL Switch or is a regional spare that happens to be housed onboard this device.
Disable split mode with the NI-2#split-mode [enable | disable] command to access each NI-2 independently.
Reload Redundancy Commands
The two redundancy commands that reload NI-2 cards are
NI-2#redundancy reload-peer—Reloads the standby NI-2 card from Flash memory.
NI-2#redundancy reload-shelf—Reloads both NI-2 cards (typically from Flash).
Changing Roles of NI-2 Cards
IOS commands can be used to manually switch the active receive port from primary to secondary and from secondary to primary. The first command is primarily used when neither NI-2 card is carrying traffic. The other commands are used to force a switch that might result in a loss of data. All the following commands are entered at the privileged EXEC (enable) prompt.
To manually switch from the active NI-2 to the standby NI-2, use the following command:
NI-2#redundancy switch-activity 6160-1#aps force atm 0/1 from working 6160-1#aps force atm 0/1 from protection
IOS commands and responses can also show an attempt to manually switch from a working interface to a faulty interface, as shown here:
NI-2#aps manual atm 0/1 from working NI-2#ATM0/1 Protection link is not available NI-2#
The aps command instructs the system to use the datastream from the named fiber interface. The manual option performs an audit before switching to ensure that the named datastream is available. The force option simply makes the switchover, even if no datastream is present on the named interface. The option from protection instructs the system to use the datastream received at the working interface instead of the protection interface. The option from working instructs the system to use the datastream received at the protection (standby) interface instead of the working interface. This configuration control allows maintenance on optical fiber systems without affecting traffic. The next step after switching the NI-2 cards is to shut down the NI-2 that is now inactive, as shown in the next command.
The NI-2#shutdown interface configuration command applies to both the active and protection OC-3/STM1 interfaces at the same time. The following command sequence shuts down all ATM traffic on the trunk port of both the active and standby NI-2 cards:
NI-2#config t NI-2#[config-if]interface atm 0/1 NI-2#[config-if]shutdown
The next command disables automatic and manual APS. After entering this command, you can proceed to replace or otherwise work on the disabled unit:
NI-2#aps lockout
Verifying Redundancy States
The NI-2#show redundancy states command shows important information about NI-2 card and port status, used to show which card is online. Following are two sample outputs from this command:
NI-2#show redundancy states
my state = 11 -ACTIVE
peer state = 8 -STANDBY READY
Mode = Duplex (The standby NI-2 is operational, otherwise this shows
simplex)
Unit = Primary (The on-line NI-2 is slot 10, the primary)
Config Sync = Enabled
File Sys Sync = Enabled
Bulk Sync = Enabled
Dynamic Sync = Enabled
Split Mode = Disabled
Manual Swact = Enabled
Communications = Up
This output shows that the NI-2 unit in slot 10 (primary) is online. The mode is duplex, indicating that a redundant NI-2 (slot 11) is installed and functional. (Note that state = 11 does not imply slot 11.) If the standby unit is not installed or not functional, the mode is simplex, as shown here:
barf1#show redundancy states
my state = 11 -ACTIVE
peer state = 8 -STANDBY READY
Mode = Duplex
Unit = Secondary
Config Sync = Enabled
File Sys Sync = Enabled
Bulk Sync = Enabled
Dynamic Sync = Enabled
Split Mode = Disabled
Manual Swact = Enabled
Communications = Up
This output shows that the NI-2 unit in slot 11 (secondary) is online. The mode is duplex, indicating that a redundant NI-2 (slot 10) is installed and functional.
With these commands, you can set up, manage, and display reports of redundancy on the Cisco IOS Software-based NI-2 cards on the 6000 series of IP DSL Switches. After you have configured the NI-2 cards for basic operations, you can proceed to configure them to perform DSL-to-ATM switching, which is explained in the next section.
Configurations for DSL-to-ATM Switching
DSL-to-ATM switching involves defining the DSL circuit parameters on the Cisco 6000 series IP DSL Switch and continuing the ATM circuit (PVC) through the NI-2 card to the ATM network. You can define the DSL circuit parameters and map the ATM circuits in either the Cisco IOS Software CLI or the CDM GUI software. This section discusses the Cisco IOS Software commands, and the next chapter discusses the CDM activities.
After you configure the Flexi line card to specify the precise ADSL type of traffic it will carry, and after the NI-2 cards automatically recognize the other line cards, you can proceed with the creation of subscriber profiles. Subscriber profiles provide various service levels for individual DSL subscribers. Profiles are discussed in the following sections.
Defining Profiles
A profile is a named list of specified values. To configure a subscriber, you attach a profile to that subscriber's port. You can change the configured items for a subscriber simply by changing that subscriber's profile.
There is a provided profile named default. You may configure the default profile with specific parameters, but you may not delete it. When you create new profiles, each new profile automatically takes on the values of the default profile unless you specifically override those values. This is useful when you want to modify one or two default parameters and apply the changes to every port in the system. This lets you avoid creating a new profile with minor changes and associating the new profile with every port in the system. Work smarter, not harder.
Except for a few dynamic operational modes, such as rate adaptation due to local impairments, port configuration takes place only through a configuration profile rather than by direct configuration. If you modify an existing profile, the change takes effect on every ADSL port linked to that profile, but only after all related connections are resynchronized (retrained).
To create or delete a DSL profile, or to select an existing profile for modification, use the following global commands:
dsl-profile profile-name—Creates a new profile.
no dsl-profile profile-name—Deletes an existing profile. A profile can be deleted only when it is no longer associated with any port.
profile-name is the name of the profile you want to create or an existing profile you want to delete or modify. Profile names are case-sensitive.
Remember that when you create a profile, it inherits all the configuration settings of the special profile named default. If you subsequently modify the special profile named default, the changes do not propagate to the previously created profiles.
The following command creates a profile called ALPHA_USERS:
c6260 (config)#dsl-profile ALPHA_USERS
Within this profile are many options for service parameters. In reality, you should not need the majority of these. In theory, you could define a unique profile for every subscriber, applying a different profile to each port. A typical service provider marketing plan would have no more than about a dozen profiles at most. For instance, the marketing department might offer both business and residential service profiles, each category of which might contain three different bit rates and other basic parameters, for a total of six levels of service. If you added a specialized service, such as for streaming video only, that might require one or two more profiles. You can see that unless the service provider's marketing department goes frantic after too much coffee in too many meetings, any DSL network should have no more than 10 or 12 profiles at most.
The following are examples of parameter options for profiles. These commands are entered in dsl profile configuration mode:
Setting the bit rate—To set the maximum and minimum allowed bit rates for the fast-path and interleaved-path DMT profile parameters, use the following command:
dmt bitrate max interleaved downstream dmt-bitrate upstream dmt-bitrate
dmt-bitrate is a multiple of 32 kbps. If you enter a nonmultiple of 32 kbps, the Cisco IOS Software parser code rejects and aborts the command.
In the following example, the command sets the maximum interleaved-path bit rate of the default profile to 8032 kbps downstream and 832 kbps upstream:
NI-2#conf t NI-2(config)#dsl-profile default NI-2(config-dsl-profile)#dmt bitrate maximum interleaved downstream 8032 upstream 832
Setting the margin—To set upstream and downstream signal-to-noise ratio (SNR) DMT margins, use the following command:
dmt margin downstream dmt-margin upstream dmt-margin
dmt-margin equals the upstream and downstream SNR margins in decibels. Values must be nonnegative integers. The range is from 0 to 15 dB. The default is 6 dB in each direction; this default is recommended by the DSL Forum and was adopted by Cisco.
CAUTION
The margin command causes the port to retrain when you change the parameter. Setting a parameter to its previous value does not cause a retrain. If a port is training when you change this parameter, the port untrains and retrains to the new parameter.
In this example, the command sets the default profile's SNR DMT margins to 6 dB upstream and 3 dB downstream:
NI-2#conf t NI-2(config)#dsl-profile default NI-2(config-dsl-profile)#dmt margin downstream 3 upstream 6
Setting check bytes—As discussed in Chapter 1, "DSL Primer," check bytes are the redundant, unaltered bytes that are used to verify DSL interleaving and deinterleaving. This interleaving process minimizes the impact of the inevitable bit errors, spreading out missed bits rather than losing a sequential string of bits. The higher the number of check bytes, the more accurately the algorithm can code and decode the straight bits, but a higher number of check bytes also means more overhead, reducing data throughput.
Here is how to define the check bytes:
NI-2#conf t NI-2 (config)#dsl-profile default NI-2 (cfg-dsl-profile)#dmt check-bytes interleaved downstream number check upstream number
number is the number of redundancy check bytes per DMT frame. Values are from 0 to 16 bytes in increments of 2 (0, 2, 4, ... , 14, 16). You can set different values for both upstream and downstream, but you must reference (specify) both directions even if the number of check bytes is equal in both directions. The default is 16 (the maximum) in both directions. You can also set the number of check bytes by turning off check bytes. This means that the system determines and uses the optimal number of check bytes for that line.
In general, you should probably use the default settings, unless and until the local transmission environment or the individual service-level agreement dictates otherwise.
Set the interleaving delay—Presuming that this is not a fast-path service (see Chapter 1's discussion of fast and interleaved paths in DSL service), the interleaving delay helps protect against impulse noise and clipping. However, it adds delay, which might not be tolerable for some applications. To set the interleaving delay parameter, use the following command:
dmt interleaving-delay downstream delay-in-usecs upstream delay-in-usecs
delay-in-usecs is the interleaving delay in microseconds. The default interleaving delay is 16000 microseconds (16 milliseconds) for both upstream and downstream directions. Allowable values are 0, 500, 1000, 2000, 4000, 8000, and 16000 microseconds.
CAUTION
CAUTION Like the margin command, this command causes the port to retrain when you change the parameter. Setting this parameter to its current value does not cause a retrain. If a port is training when you change the value, the port untrains and retrains to the new value.
In the following example, the command sets the default profile's interleaving delay to 2000 microseconds downstream and 4000 microseconds upstream:
NI-2#conf t NI-2(config)#dsl-profile default NI-2(config-dsl-profile)#dmt interleaving-delay downstream 2000 upstream 4000
The four parameters are not all the options available, but they are probably the most common settings made for typical DSL networks. You can even safely use the default settings, such as 6 dB for the margin, and just define the bit rate, for a very simple and quick beginning profile. The very simplest starting procedure is to keep using the default profile, possibly making a few changes to its parameters, which is already attached to every port until you specify a new profile.
In this case, after defining the new profile with the bit rates, margin, check bytes, and interleave delay, you can proceed to assign the profile to the port(s) desired. At this time you cannot attach a profile to a group or range of ports, so you must address each port individually.
Attaching and Detaching a Profile
To attach a profile to or detach a profile from a specific port, use the following interface commands:
dsl profile profile-name (to attach)
no dsl profile profile-name (to detach from the port)
profile-name is the profile you want to attach to or detach from the selected port.
In the following example, the command attaches the profile ALPHA_USERS to slot 20, port 1:
NI-2#conf t NI-2(config)#int atm 20/1 (Enters interface configuration mode for port 20/1) NI-2(config-if)#dsl profile ALPHA_USERS (Attaches ALPHA_USERS profile to this port)
In the following example, the command detaches the profile ALPHA_USERS from slot 20, port 1:
NI-2#conf t NI-2(config)#int atm 20/1 (Enters interface configuration mode for port 20/1) NI-2(config-if)#no dsl profile ALPHA_USERS (Detaches ALPHA_USERS profile from this port) NI-2(config-if)#exit
The preceding commands detach this particular instance (application) of the profile from this particular port. However, the original definition of the profile, the class, still exists in the overall configuration. After you have detached the profile from the port, then and only then can you delete the original definition of the profile from the overall configuration, if you're sure you will never use this profile again. To do this, use the following command:
NI-2#conf t NI-2(config)#no dsl-profile ALPHA_USERS
PVCs
Having defined and attached your profile, you can move on to creating an ATM connection from the line card port to the network trunk. The simplest type of connection is a PVC, which is the starting basis for the more-sophisticated soft-PVC and Permanent Virtual Path (PVP).
PVCs must be configured in both the IP DSL Switch and the ATM switch cloud. PVCs remain active until the circuit is removed from either configuration.
To create a PVC on an ATM interface, use the atm pvc interface configuration command. The no form of this command removes the specified PVC. The labor-saving news is that PVCs are bidirectional and need to be removed from only one direction or the other.
Here's the syntax:
atm pvc vpi vci int atm [slot/port] vpi vci
vpi is the virtual path identifier for this PVC. The vpi value is unique on only a single link, not throughout the ATM network, because it has local significance only. The vpi value must match that of the switch.
vci is the ATM network's virtual channel identifier. It is in the range of 0 to 1 less than the maximum value set for this interface by the ATM per-VC per-VP command. The vci value is unique on only a single link.
As an example, suppose that a DSL circuit is connected to DSL port 1 on line card 19. On that DSL side, it is configured as an ATM PVC using the virtual path of 0 and the virtual channel of 33. Here are the commands to switch that incoming connection to VPI 0, VCI 100 outbound on the network trunk, which is the ATM interface 0/1:
6260(config)#int atm 19/1 6260(config-if)#atm pvc 0 33 int atm 0/1 0 100
In a subtended configuration, you must configure the passthrough connections from the subtended trunk to the network trunk. In this case, you can build on the previous line card-to-trunk definitions to make the same PVC follow through to the host device's ATM trunk, 0/1 again. Bear in mind that the PVC definition turned the PVC 0/100 loose on this IP DSL Switch's incoming trunk 0/2. Here are the commands to switch the passthrough (subtended) PVC through this IP DSL Switch onto the network trunk, which is ATM 0/1:
6260(config)#int atm 0/2 6260(config-if)#atm pvc 0 100 int atm 0/1 0 200
Even if you use the same numbers for both ends of the connection, both the line card/port and the trunk or the trunk-trunk connection, you must specify the whole line, both incoming and outgoing identifiers.
You should be starting to realize that configuring each DSL subscriber's port on the IP DSL Switch with PVCs is quite labor-intensive. Remember also that you can configure multiple PVCs on the Cisco 827 DSL router—that is, one PVC for voice service and another for data traffic. You can also create two or more PVCs on each line card port on the IP DSL Switch. Obviously, using nothing but PVCs would be inefficiently burdensome. In the interest of working smarter, not harder, consider the next two labor-saving ATM connections.
Soft-PVCs (SPVCs)
The SPVC is a combination of permanent circuits, manually configured at each end of the connection, and an SVC through the middle of the connection. The switched circuit depends on the ATM format's internal communications and routing protocols—specifically, the autoconfigured point-to-point signaling connection using VCI 5. (For more information, refer to Appendix B, "ATM Overview.")
Soft-PVCs have two main advantages. The first advantage is its flexible sustainability. If a particular link is unavailable, as with a cable cut, the SPVC takes advantage of the ATM network's other paths to reach its destination. This automatic PVC rerouting does not require human intervention, unlike the PVC in the case of connection unavailability. The second SPVC advantage is its efficiency in configuration labor. You can trust the ATM signaling protocols to automatically allocate available identifiers, both VPIs and VCIs, at each interface, eliminating the need to manually define each new connection.
However, these two advantages also suggest the SPVC's disadvantages. First, the SPVC requires more overhead to accommodate the signaling and updating required to maintain the network knowledge. Second, the SPVC is harder to trace, unlike the PVC, which is mapped to a known set of identifiers, because the SPVC takes on dynamic VPIs and VCIs at each interface.
Overall, many providers prefer to save human labor and tax the system itself, so you should know how to create a soft-PVC. You can use these steps:
blockquote
Step 1 Find the target device's ATM address, such as the host IP DSL Switch in a subtending configuration, or the Layer 3 termination device, such as the 6400 UAC. You can do this with the IOS command show atm addresses on the target device. Just as obvious as the command is the listing of ATM addresses, with their own heading of Soft-PVC Addresses in the case of the 6400. The ATM address probably looks like this:
47.0091.8100.0000.0030.7b2d.0001.4000.0c80.0010.00
NOTE
For efficiency and to prevent human hand-copying errors, copy that ATM address to your computer's software clipboard.
Step 2 Telnet back (or otherwise connect) to the IP DSL Switch's NI-2. You cannot duplicate the existing PVC identifiers, so you must either remove the existing PVC or use a different set of identifiers. (Remember that you will have the same numbers of VCIs on differently-numbered VPIs as long as those combinations are still unique.)
Step 3 Map the new soft-PVC from the line card port to the target ATM address rather than out the DSLAM's network trunk interface as you would for a standard PVC. You specify that destination address rather than the outgoing network trunk. That is, the only interface you specify is the line card/port, not the network trunk interface. Following are the commands:
NI-2(config)#int atm 21/4 (for the 21st line card's fourth port) NI-2(config-if)#atm soft-pvc 0 101 dest-address 47.0091.8100.0000.0030.7b2d.0001.4000.0c80.0010.00 0 200
The command in interface configuration mode is actually all on one line. You can see why it's easier to paste the ATM address you obtained in the first step! Notice also that you must specify the exiting VPI and VCI—in this case, VPI 0 and VCI 200. That's how the circuit is identified at the other end, the target ATM device, although it takes on seemingly random identifiers in the ATM network between the two end devices. This is shown in Figure 6-7 (which is also repeated in Appendix B).
)
Figure
6-7
PVPs
Another type of labor-saving ATM connection is a PVP. As mentioned in Appendix B's discussion of basic ATM, a PVP is a manually configured connection that carries a bundle of virtual circuits. This is commonly implemented between ATM switches within an ATM network (node to node). The advantage of this type of connection is that a single VPI configured through several ATM switches carries thousands of VCs without the need to individually configure them. The common VPI means that any single channel with that VPI is automatically assimilated into the larger path without having to configure each circuit like adding threads. Many service providers use a PVP to group the individual PVCs from a subtended IP DSL Switch so that the VPI highlights the common source as the subtended connections traverse the hosting devices. Another use of PVPs is to group connections with a common service-level agreement, according to an obvious mapping scheme that matches a VPI with a type of DSL service.
The first disadvantage of the PVP is that you cannot extract or work with a single PVC within the larger pipe without rebuilding the entire PVP. Among other considerations, this means that you must be careful when identifying the starting PVCs, because the system assimilates all the common VPIs regardless of whether you want to bundle them into that PVP. Second, as with the PVC, you must define the PVP at each interface through which it traverses (although defining a single element is still much easier than defining the thousands of separate PVCs). A third disadvantage is like the PVC's fragility: If a link is broken, as with a cable cut, the PVP must be manually reconfigured.
Following are the commands to configure a PVP:
NI-2(config)#int atm 0/2—This command begins to configure the first subtending trunk interface, ATM 0/2.
NI-2(config-if)#atm pvp 0 int atm 0/1 0—In the interface configuration command, notice that you specify only the VPI—0 in this case—on both ends, the subtending trunk of 0/2 and the network trunk of 0/1. This makes VPI 0 unavailable for any incoming connections on this host IP DSL Switch, and you must have previously identified all the desired incoming connections on the subtended IP DSL Switch with the common VPI of 0.
You can repeat the PVP definition at the next ATM device, whether it is another IP DSL Switch in a subtended daisy chain or tree, or any other device. You can even change the PVP number as you did the PVC earlier, like this:
Nextdevice(config)#int atm 0/2 Nextdevice(config-if)#atm pvp 0 int atm 0/1 14
In the second command, all the individual PVCs, which started their lives with the VPI of 0, are now grouped in the PVP numbered 14.
Configuring Inverse Multiplexing Over ATM (IMA)
As discussed at length in Chapter 4, IMA is most common on the Cisco 6015 IP DSL Switch, but it is available on the other switches in the 6000 series as well. As a very brief reminder here, the T1/E1 IMA feature aggregates multiple low-speed links (T1/E1) into one or more IMA groups. These multiple ATM links act as a single ATM physical layer element.
To enable IMA, you can configure any WAN interface (the DS3, any T1 link, any E1 link, or any IMA group) as the trunk. When you configure a T1 link or an IMA group as the trunk, the DS3 port is disabled. When you select the DS3 port as the trunk, the T1 links and IMA groups are all treated as subtended ports.
Configuring IMA involves three major processes:
Configuring a trunk interface
Configuring T1/E1 interfaces
Configuring IMA interfaces
First, configure the trunk interface with the following command, which designates the interface to use as the trunk—in this case, the 0/1 (network) trunk:
6015(config)#atm ni2-switch trunk atm 0/1
Next, select the link's transmit clock source, which you learned about earlier:
6015(config-if)#clock source network-derived
Select the link's framing type, which must match on both sides of that link:
6015(config-if)#framing m23adm
Enable DS3 cell payload scrambling on the link; scrambling is required if you use ami line coding:
6015(config-if)#scrambling cell-payload
Specify the cable length line build-out (short or long), followed by mandatory values: the length following short, or the gain and margin value following long. You can view the acceptable lengths, such as 0 to 133 feet for short, by including the ? option after the long or short commands. The default setting is long haul with gain36 and 0db (lbo long gain36 0db):
6015(config-if)#lbo short
Next, configure each T1/E1 interface that will go into the IMA group(s), starting in interface configuration mode for each interface in turn:
6015(config)#interface atm 0/2
If ami line coding is selected, as it is in the next command for this T1 link, you must have enabled cell scrambling on the link. T1 and/or E1 links have different, specific options, although ami applies to both T1 and E1 links. The defaults are b8zs for the T1s and hdb3 for the E1s.
6015(config-if)#linecode ami
Next, select the frame type for the T1 or E1 data links. The framing type must match on both sides of the link. The defaults are as follows:
E1—pcm30
T1—esf
DS3—cbitadm
6015(config-if)#framing esf (or framing pcm30 for the E1)
Specify the line build-out (LBO) length as either short or long, followed by the appropriate parameters, as you did earlier for the trunk interface. Here is an example of the lbo command in this case:
6015(config-if)#lbo short 133
Now you are ready for the third major step, which is to configure the IMA interfaces themselves. You repeat the following command sets for each IMA interface you want to configure:
6015(config)#interface atm 0/2 (first T1/E1 to be assigned to an IMA group)
Assign the ATM interface to an IMA group (numbered from 0 to 3, for a total of four possible IMA groups). After the interface is assigned to an IMA group, individual ATM functionality is no longer available on the link:
6015(config-if)#ima-group 2
Enable the individual link by canceling the shutdown state:
6015(config-if)#no shutdown
Now that you have created an IMA interface from the individual links, you can begin configuring the IMA interface as a whole:
6015 (config-if)#interface atm0/ima2
Select the transmit clock mode for the selected IMA group:
6015(config-if)#ima clock-mode independent
Enter the maximum differential delay in milliseconds for the selected IMA group. Although the ranges are different for T1s and E1s, the default for both is 25 milliseconds, which is the minimum delay for both these standards:
6015(config-if)#ima differential-delay-maximum 68
Enter the minimum number of links that need to be operational for the selected IMA group:
6015(config-if)#ima active-links-minimum 2
Enable the IMA group by canceling the shutdown state:
6015(config-if)#no shutdown
This completes the three major processes for configuring the NI-2 for IMA. The next section describes the commands to verify the configuration.
Verifying IMA Status
After you have configured IMA, you should verify the operational status of the IMA interfaces using these show commands:
6015#show ima interface—Displays information about all IMA groups and the links in those groups.
6015#show interface atm0/ima2—Displays interface configuration, status, and statistics for the IMA interface.
6015#show controllers—Displays information about current settings and performance at the physical level. You saw detailed examples of this command earlier, in the section "APS-Related CLI Commands."
6015#show controller atm0/ima2—Displays diagnostic information for the specified IMA group.
6015#show ima interface atm0/ima2—Displays configuration information and operational status for the specified IMA group.
6015#show ima interface atm0/2—Displays information for a single link in an IMA group.
6015#show ima counters—Displays IMA statistics in 15-minute intervals, with 24-hour totals.
Now you can verify your work with sample configurations. The first sample configuration describes how to configure the topology shown in Figure 6-8, which consists of the following:
An IMA group containing four links as a trunk interface
Two IMA groups, each containing two links, connecting subtended Cisco 6000 series IP DSL Switch chassis
)
Figure
6-8 IMA Trunk with IMA Subtended Chassis
Here is the configuration, shown in the running config output:
atm ni2-switch trunk ATM0/IMA0 !Configures interface ATM0/IMA0 as the trunk! ! interface ATM0/0 no ip address no ip route-cache atm maxvp-number 0 atm maxvc-number 4096 atm maxvci-bits 12 ! interface Ethernet0/0 ip address 192.168.1.1 255.255.255.0 no ip route-cache ! interface ATM0/1 no ip address no ip route-cache shutdown no atm ilmi-keepalive ! interface ATM0/2 no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive clock source loop-timed scrambling cell-payload linecode ami lbo short 133 ima-group 0 !Adds this interface to IMA group 0! ! interface ATM0/3 no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive clock source loop-timed scrambling cell-payload linecode ami lbo short 133 ima-group 0 !Adds this interface to IMA group 0! ! interface ATM0/4 no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive clock source loop-timed scrambling cell-payload linecode ami lbo short 133 ima-group 0 !Adds this interface to IMA group 0! ! interface ATM0/5 no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive clock source loop-timed scrambling cell-payload linecode ami lbo short 133 ima-group 0 !Adds this interface to IMA group 0! ! interface ATM0/6 no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive clock source loop-timed scrambling cell-payload linecode ami lbo short 133 ima-group 1 !Adds this interface to IMA group 1! ! interface ATM0/7 no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive clock source loop-timed scrambling cell-payload linecode ami lbo short 133 ima-group 1 !Adds this interface to IMA group 1! ! interface ATM0/8 no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive clock source loop-timed scrambling cell-payload linecode ami lbo short 133 ima-group 2 !Adds this interface to IMA group 2! ! interface ATM0/9 no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive clock source loop-timed scrambling cell-payload linecode ami lbo short 133 ima-group 2 !Adds this interface to IMA group 2! ! interface ATM0/IMA0 !IMA group 0 configuration! no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive ima active-links-minimum 2 ima clock-mode independent ima differential-delay-maximum 68 ! interface ATM0/IMA1 !IMA group 1 configuration! no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive ima active-links-minimum 2 ima clock-mode independent ima differential-delay-maximum 68 ! interface ATM0/IMA2 !IMA group 2 configuration! no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive ima active-links-minimum 2 ima clock-mode independent ima differential-delay-maximum 68 ! interface ATM0/IMA3 no ip address no ip route-cache shutdown no atm ilmi-keepalive
This output shows the configuration for an IMA trunk with IMA-subtended chassis for the Cisco 6000 series IP DSL Switch. The next configuration is for the topology shown in Figure 6-9.
)
Figure
6-9 DS3 Trunk with IMA and T1 Subtended Chassis
This configuration contains a combination of IMA, T1, and DS3 interfaces:
atm ni2-switch trunk ATM0/1 !DS3 is the default trunk! ! interface ATM0/0 no ip address no ip route-cache atm maxvp-number 0 atm maxvc-number 4096 atm maxvci-bits 12 ! interface Ethernet0/0 ip address 192.168.1.1 255.255.255.0 no ip route-cache ! interface ATM0/1 no ip address no ip route-cache no atm ilmi-keepalive ! interface ATM0/2 no ip address no ip route-cache no atm ilmi-keepalive ima-group 0 !Adds this interface to IMA group 0! ! interface ATM0/3 no ip address no ip route-cache no atm ilmi-keepalive ima-group 0 !Adds this interface to IMA group 0! ! interface ATM0/4 no ip address no ip route-cache no atm ilmi-keepalive ima-group 0 !Adds this interface to IMA group 0! ! interface ATM0/5 no ip address no ip route-cache no atm ilmi-keepalive ima-group 0 !Adds this interface to IMA group 0! ! interface ATM0/6 !T1 configuration! no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive clock source loop-timed scrambling cell-payload linecode ami lbo short 133 ! interface ATM0/7 !T1 configuration! no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive clock source loop-timed scrambling cell-payload linecode ami lbo short 133 ! interface ATM0/8 !T1 configuration! no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive clock source loop-timed scrambling cell-payload linecode ami lbo short 133 ! interface ATM0/9 !T1 configuration! no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive clock source loop-timed scrambling cell-payload linecode ami lbo short 133 ! interface ATM0/IMA0 !IMA group 0 configuration! no ip address no ip route-cache no ip mroute-cache no atm ilmi-keepalive ima active-links-minimum 4 ima clock-mode independent ima differential-delay-maximum 68 ! interface ATM0/IMA1 no ip address no ip route-cache shutdown no atm ilmi-keepalive ! interface ATM0/IMA2 no ip address no ip route-cache shutdown no atm ilmi-keepalive ! interface ATM0/IMA3 no ip address no ip route-cache shutdown no atm ilmi-keepalive
Verifying NI-2 Processes with show Commands
Several general and DSL-specific show commands can help you verify proper operations on the NI-2. The first command is probably the most common Cisco IOS Software command. It produces output that is valuable for DSL and ATM troubleshooting. The other commands are more specific to DSL and/or ATM. These show commands are as follows:
show running-configuration
show atm vc (traffic and other options)
show hardware (slot and chassis)
show dsl profile
show facility-alarm status
show environment
show network-clocks
show ATM Status
Each of these is detailed in the following list. It includes the pertinent information you need to monitor DSL activity through the NI-2 card on the Cisco 6000 series of IP DSL Switches:
show running-configuration
This command tells you which ports are attached to each profile. You can obtain more-specific reporting for selected profiles by using the show dsl profile command.
The following example shows the running configuration:
alpha_c6260#show running-config Building configuration... Current configuration: ! ! Last configuration change at 12:58:27 EDT Fri June 14 2002 ! NVRAM config last updated at 14:13:58 EDT Thu June 13 2002 ! version 12.2 !Notice the more generic version designator! no service pad service timestamps debug uptime service timestamps log uptime no service password-encryption service internal ! hostname alpha_c6260 ! boot system flash:NI-2-dsl-mz.12-2.DA slot 1 atuc-1-4dmt !These are the line cards, all four-port DMT cards in this chassis; remember that slots 10 and 11 are reserved for the NI-2 card(s) and are ignored here! slot 2 atuc-1-4dmt slot 3 atuc-1-4dmt slot 4 atuc-1-4dmt slot 5 atuc-1-4dmt slot 6 atuc-1-4dmt slot 7 atuc-1-4dmt slot 8 atuc-1-4dmt slot 9 atuc-1-4dmt slot 12 atuc-1-4dmt no logging monitor enable password lab ! dsl-profile default !As with almost all Cisco show commands, if the default values have not been changed, no details are shown for any default parameters, such as this default profile. You can display the precise default values with the show dsl profile command.! ! dsl-profile ALPHA_USERS dmt interleaving-delay downstream 3 upstream 6 dmt bitrate maximum interleaved downstream 2048 upstream 256 ! dsl-profile test !This profile has not been defined yet beyond its name, so no values are shown.! ! dsl-profile alpha_677 dmt interleaving-delay downstream 0 upstream 0 dmt bitrate maximum interleaved downstream 8032 upstream 864 ! dsl-profile alpha-677 dmt bitrate maximum interleaved downstream 8032 upstream 864 ! dsl-profile jurgen dmt bitrate maximum interleaved downstream 8032 upstream 864 dsl-profile train network-clock-select revertive !This clocking selection has been changed from the default value of non-revertive, which is much more typical in service provider environments.! network-clock-select 1 ATM0/1 network-clock-select 2 system ip subnet-zero ip host-routing ip host zeppelin 1.0.0.253 ip domain-name cisco.com ip name-server 171.69.204.11 ! atm address 47.0091.8100.0000.0077.d0fe.4301.0077.d0fe.4301.00 atm address 47.0091.8100.0000.00e0.b0ff.b501.00e0.b0ff.b501.00 atm address 47.0091.8100.0000.0050.0fff.cc01.0050.0fff.cc01.00 atm router pnni no aesa embedded-number left-justified node 1 level 56 lowest redistribute atm-static ! clock timezone EDT -5 clock summer-time EDT recurring ! process-max-time 200 ! interface ATM0/0 !This is the backplane trunk, which you can think of as the backplane itself; unless you want to configure a PVC for in-band management, you need not configure this trunk at all, leaving the default values as they are.! no ip address no ip mroute-cache atm cac service-category abr deny atm maxvp-number 0 ! interface Ethernet0/0 ip address 171.69.204.250 255.255.255.0 no ip proxy-arp no ip mroute-cache no keepalive ! interface ATM0/1 no ip address no atm ilmi-keepalive atm cac service-category abr deny atm manual-well-known-vc atm pvc 0 5 pd on rx-cttr 3 tx-cttr 3 interface ATM0/0 0 any-vci encap qsaal atm pvc 0 16 pd on rx-cttr 3 tx-cttr 3 interface ATM0/0 0 any-vci encap ilmi atm pvc 0 18 pd on rx-cttr 3 tx-cttr 3 interface ATM0/0 0 any-vci encap pnni clock source loop-timed ! interface ATM0/2 no ip address shutdown !Shutdown is the default state of all interfaces, and in this case, the subtend trunk ATM0/2 is left shut down because there is no subtending on this chassis.! no atm ilmi-keepalive atm cac service-category abr deny ! interface ATM1/1 no ip address dsl subscriber RayBudge dsl profile alpha_676 no atm ilmi-keepalive atm cac service-category abr deny atm pvc 0 35 interface ATM0/1 0 101 !Here is the PVC that is designated 0/35 as it enters from the DSL subscriber side and is designated 0/101 as it leaves on the network trunk ATM 0/1.!
show atm vc
The details of this command and its output are explained after the output:
6160-93#sho atm vc Interface VPI VCI Type X-Interface X-VPI X-VCI Encap Status ATM0/0 0 35 PVC ATM0/1 0 16 ILMI UP ATM0/0 0 36 PVC ATM0/2 0 16 ILMI DOWN ATM0/0 0 37 PVC ATM0/1 0 5 QSAAL UP ATM0/0 0 38 PVC ATM0/2 0 5 QSAAL DOWN ATM0/0 0 39 PVC ATM0/1 0 18 PNNI UP ATM0/1 0 5 PVC ATM0/0 0 37 QSAAL UP ATM0/1 1 34 PVC ATM1/1 1 1 UP ATM0/1 1 36 PVC ATM1/2 1 1 UP ATM0/1 1 44 PVC ATM2/2 1 1 DOWN ATM1/1 1 1 PVC ATM0/1 1 34 UP ATM1/2 1 1 PVC ATM0/1 1 36 UP ATM2/2 1 1 PVC ATM0/1 1 44 DOWN
This output displays statistics for all PVCs, both manually created and those that were autocreated by the system for ATM signaling and management. All ATM interfaces on the IP DSL Switch are reflected, although you can specify a particular interface's connections to display, such as a particular DSL port. The Status field is either UP or DOWN.
ATM VCs are shown twice, once on each interface. For instance, when you look a bit more than halfway down the second and third columns, VCC 1/34 is first shown on the network trunk interface ATM0/1, mapped to the Cisco 6400 from the line card interface ATM1/1, where it is connected to the CPE modem as 1/1. Then the line card interface itself is shown further down, as you see in the first column, mapping 1/1 to the interface ATM0/1.
To display all ATM virtual circuits (PVCs, soft-PVCs, and SVCs) and traffic information, you can use the show atm vc command. You can also use the command show atm vc | interface interface-number, where interface interface-number specifies the interface number or subinterface number of the PVC or SVC. This displays all VCs on the specified interface or subinterface.
In this example, ATM 0/2 is shut down, because subtending is not being used. Therefore, the signaling and OAM protocols in the reserved circuits are also down, such as PVC 0/36 in the second line of the list.
The following is an example of a more-specific display, using optional parameters where traffic displays the virtual channel cell traffic:
NI-2#show atm vc traffic int atm Interface VPI VCI Type rx-cell-cnts tx-cell-cnts ATM0/0 0 35 PVC 43 38 ATM0/0 0 36 PVC 0 0 ATM0/0 0 37 PVC 27 29 ATM0/0 0 38 PVC 0 0 ATM0/0 0 39 PVC 64 144 ATM0/1 0 5 PVC 29 27 ATM0/1 0 16 PVC 38 43 ATM0/1 0 18 PVC 144 64 ATM0/1 0 100 PVC 0 0 ATM0/2 0 5 PVC 0 0 ATM0/2 0 16 PVC 0 0 ATM19/1 0 33 PVC 0 0
You can specify a particular interface to show the connections on that interface only. You can also use the command show atm vp if this is a subtended host with PVPs passing through it from the subtended system.
show hardware status
You can display information about the chassis type and the physical cards in the chassis and determine whether the power supply and fan modules are present:
NI-2#show hardware (Displays all hardware, as shown here:) Chassis Type: C6260 Slot 1 : ATUC-1-4DMT Slot 17: ATUC-1-4DMT Slot 2 : ATUC-1-4DMT Slot 18: ATUC-1-4DMT Slot 3 : ATUC-1-4DMT Slot 19: ATUC-1-4DMT Slot 4 : ATUC-1-4DMT Slot 20: ATUC-1-4DMT Slot 5 : ATUC-1-4DMT Slot 21: ATUC-1-4DMT Slot 6 : ATUC-1-4DMT Slot 22: ATUC-1-4DMT Slot 7 : ATUC-1-4DMT Slot 23: ATUC-1-4DMT Slot 8 : ATUC-1-4DMT Slot 24: ATUC-1-4DMT Slot 9 : ATUC-1-4DMT Slot 25: ATUC-1-4DMT Slot 10: NI-2-155SM-155SM Slot 26: ATUC-1-4DMT Slot 11: EMPTY Slot 27: ATUC-1-4DMT Slot 12: ATUC-1-4DMT Slot 28: ATUC-1-4DMT Slot 13: ATUC-1-4DMT Slot 29: ATUC-1-4DMT Slot 14: ATUC-1-4DMT Slot 30: ATUC-1-4DMT Slot 15: ATUC-1-4DMT Slot 31: ATUC-1-4DMT Slot 16: ATUC-1-4DMT Slot 32: ATUC-1-4DMT Fan Module 1: Present 2: Present Power Supply Module 1: Not Present 2: Present
The show hardware chassis command shows the manufacturing data for the NI-2 motherboard and daughter card, I/O controller, power module, and backplane, plus the chassis type, chassis name, manufacturer's name, hardware revision, serial number, asset ID, alias, and CLEI code.
show dsl profile
This command displays all profiles unless you use the option profile-name at the end of the command to specify a particular profile.
The following example displays the command profile named ALPHA_USERS:
NI-2#show dsl profile ALPHA_USERS dsl profile ALPHA_USERS: Alarms Enabled: NO ATM Payload Scrambling: Enabled DMT profile parameters Maximum Bitrates: Interleave Path: downstream: 8032/kbs, upstream: 864/kbs Minimum Bitrates: Interleave Path: downstream: 0/kbs, upstream: 0/kbs Margin: downstream: 3 db, upstream: 3 db Interleave Delay: downstream: 0 usecs, upstream: 0 usecs Check Bytes (FEC): Interleave Path: downstream: 16, upstream: 16 R-S Codeword Size: downstream: auto, upstream: auto Trellis Coding: Disabled Overhead Framing: Mode 1 Bit-Swap: Enabled Bit-Swap From Margin: 3 dB Bit-Swap To Margin: 3 dB Operating Mode: Automatic Training Mode: Standard SDSL profile parameters CAP profile parametersThe last two lines, for SDSL profile parameters and CAP profile parameters, are legacy provisions for these obsolescent modulations. In this case, no profile named ALPHA_USERS has been defined for SDSL or CAP, so these display areas are blank.
show facility-alarm status
This command shows the current major and minor alarms and the thresholds for all user-configurable alarms on a Cisco IP DSL Switch.
The following are different examples of the output. The first example shows a single major alarm and a single informational notice:
NI-2#show facility-alarm status System Totals Critical: 0 Major: 1 Minor: 0 Source: Fan Slot 0 Severity: MAJOR Description: 1 Not detected or missing Source: Slot 19 Severity: INFO Description: 4 Module was detected
The next example of the show facility-alarm status command shows one critical alarm, one major alarm, and one informational notice:
NI-2#show facility-alarm stat System Totals Critical: 1 Major: 1 Minor: 0 Source: NI-2 Module Severity: MAJOR Description: 1 Loss of active clock sync Source: Slot 19 Severity: INFO Description: 4 Module was detected Source: ATM0/1 Severity: CRITICAL Description: 6 Line RDI
show environment
This command displays temperature, voltage, and chassis status information. The show environment command has two valuable options—all and table.
all lists temperature readings, fan status, and chassis status. table displays the temperature and voltage thresholds and lists the ranges of environmental measurements that are within the specified ranges.
Here is an example:
NI-2#show environment all Slot 1 Slot 2 Power/Fan Presence: Power Module: No Yes Fan Tray: Yes Yes Power Modules: 48 VDC voltage: 0 volts 48 volts 48 VDC current: 0 amps 1 amps 24 VDC thresh.: 0 volts 20 volts Power Fault: No No Fans: Fan Number 0: on on Fan Number 1: on on Fan Number 2: on on Fan Number 3: on on Temperature readings: NI-2 inlet: 21C/69F NI-2 outlet: 27C/80F Slot 1 PM internal: 0C/32F Slot 1 PM external: 0C/32F Slot 2 PM internal: 23C/73F Slot 2 PM external: 15C/59Fshow network-clocks
You can see which ports are designated as network clock sources with this command. For example:
NI-2#show network-clocks PLL failed: 42; PLL Passed: 2741 !(PLL stands for Phase Locked Loop)! FAIL: 0; NCO: E391; REF: E390; ERR: 1; ERR_D: -1; MAG: 2; clock configuration is NON-Revertive Priority 1 clock source: ATM0/1 Priority 2 clock source: No clock Priority 3 clock source: No clock Priority 4 clock source: No clock Priority 5 clock source: System clock Current clock source:System clock, priority:5 Nettime Config Register Contents: SLOCK:0, TLOCK:0, NFAIL:0, E1:1, NSEL:0 BITS Register Contents: CR1: C8, CR2: 0, CR3: 0, ICR: 0, TSR: C1, PSR: 11, ESR: 77, CR4: 0 BITS Source configured as: E1 Short Haul, ITU G.703 pulse, 120 ohm TP/75 ohm Coax, 12 db gain
Confirming the interface status
You can use the show atm status command to confirm the status of ATM interfaces.
For example:
NI-2#show atm status NUMBER OF INSTALLED CONNECTIONS: (P2P=Point to Point, P2MP=Point to MultiPoint, MP2P=Multipoint to Point) Type PVCs SoftPVCs SVCs TVCs PVPs SoftPVPs SVPs Total P2P 1 0 0 0 0 0 0 1 P2MP 0 0 0 0 0 0 0 0 MP2P 0 0 0 0 0 0 0 0 TOTAL INSTALLED CONNECTIONS = 1 PER-INTERFACE STATUS SUMMARY AT 10:27:54 EDT Thu Jun 10 2002: Interface IF Admin Automation :-Cfg ILMI Addr SSCOP Hello Name Status Status Status Reg State State State ------------- ------- ------------ -------- --------- ATM0/0 UP up n/a UpAndNormal Idle n/a ATM0/1 UP up n/a n/a Idle down ATM0/2 DOWN down waiting n/a Idle n/a
Aggregator/Concentrator: Cisco 6400
The 6400 UAC provides both ATM switching and Layer 3 IP routing for the ATM signals coming from the DSL network. This section explains the 6400 configuration for a variety of scenarios, starting with redundancy commands and ending with sophisticated routing topologies.
You might want to review the 6400 hardware components that were discussed in Chapter 4 to refresh your memory and to help you better understand the Cisco 6400 ATM interfaces shown in Figure 6-10.
)
Figure
6-10 Cisco 6400 ATM Interfaces Through the Node Switch Processor
Bear in mind that there are eight full-height slots into which you can fit any combination of half-height node line cards (NLCs), full-height NLCs (the OC-12 variant), and/or full-height second-generation node route processors (NRP-2s).
The upper, half-height NLC is identified as subslot 0, as is the entire full-height NLC. A half-height NLC in the lower subslot is identified as occupying subslot 1. The first port on the half-height NLCs, and the only port on the full-height NLCs (OC-12/STM4), are designated as port 0.
The 6400 control is through the full-height, optionally redundant node switch processor (NSP), centered on the 6400 in a dedicated slot. Therefore, all interfaces are referenced from the NSP's point of view. The NSP is the only avenue to configure the NRP-2 and NLC. All 6400 cards are connected via the ATM backplane to the NSP. This interface is known as ATM INT 0/0/0 and can be thought of as the interface to the NSP, which itself is the interface to the entire 6400 device.
NRP-2
This section describes basic setup and initial configuration for the second-generation NRP blade on the Cisco 6400 (NRP-2), as well as redundancy options for all modules.
Cisco 6400 Redundancy Configurations
All the modules on the Cisco 6400 are optionally redundant. This section explains how to configure the 6400 for redundancy.
Memory Considerations for Redundancy
When you configure redundancy between two NRPs or two NSPs, the two cards must have identical memory capabilities and hardware specifications. Check each card in a redundant pair, and make sure they share the following parameters:
DRAM size
Flash memory size
PCMCIA disk size (NSP only)
Hardware version (module part number)
If redundancy is configured between two cards with different amounts of memory or disk capacity, the Cisco 6400 displays a warning message. Depending on which card is identified as the primary card, the Cisco 6400 performs the following actions:
If the primary card has more memory than the secondary card, the Cisco 6400 shuts down the secondary card.
If the secondary card has more memory than the primary card, the Cisco 6400 displays a message indicating that the secondary card has more memory than the primary card. This configuration causes redundancy to be disabled if the secondary card is activated.
Redundant NSPs
Both NSP slots are numbered slot 0 for consistent interface identification between primary and secondary devices. Nevertheless, the left NSP slot is labeled slot A and the right slot is labeled slot B to distinguish between the two slots when required. You do not need to explicitly specify redundancy between NSPs using slot identification. If two NSPs are installed in the Cisco 6400, they automatically act as a redundant pair.
You can use Enhanced High System Availability (EHSA) redundancy for simple hardware backup or for software error protection. Hardware backup protects against NSP card failure, because you configure both NSP cards with the same software image and configuration information. Additionally, you configure the system to automatically synchronize configuration information on both cards when changes occur.
Software error protection protects against critical Cisco IOS Software errors in a particular release, because you configure the NSP cards with different software images but use the same configuration. If you are using new or experimental Cisco IOS Software, consider using the software error protection method.
After you have installed the second NSP, you can verify NSP redundancy with the show redundancy command (the results might vary slightly with the Cisco IOS Software version):
Switch#show redundancy ! NSP A:Primary NSP B:Secondary ! Secondary NSP information: Secondary is up Secondary has 131072K bytes of memory. ! User EHSA configuration (by CLI config): secondary-console = off keepalive = on config-sync modes: standard = on start-up = on boot-var = on config-reg = on calendar = on ! Debug EHSA Information: ! Primary (NSP A) ehsa state:SANTA_EHSA_PRIMARY Secondary (NSP B) ehsa state:SANTA_EHSA_SECONDARY ! EHSA pins: peer present = 1 peer state = SANTA_EHSA_SECONDARY crash status:this-nsp=NO_CRASH(0x1) peer-nsp=NO_CRASH(0x1) ! EHSA related MAC addresses: this bpe mac-addr = 0000.0c00.0003 peer bpe mac-addr = 0000.0c00.0004 ! Switch#
To ensure that the configuration is consistent between redundant NSPs or NRPs, you can configure automatic synchronization between the two devices. You have the option of synchronizing just the startup configuration, the boot variables, the configuration register, or all three configurations. Boot variables are ROM monitor (ROMMON) environment variables used to control the booting process. The configuration register, stored in NVRAM, contains startup time parameters for the system. For more information about the booting process, see the Cisco IOS Configuration Fundamentals Configuration Guide. Frankly, though, you might as well use the default standard synchronization unless you have good reason to do otherwise.
After the configuration is complete, you can disable autoconfiguration using the no command. The default setting for individual synchronizable options is no auto-sync.
The following example shows how to synchronize the configurations on two redundant NSPs:
Switch#config term Switch(config)#redundancy Switch(config-r)#main-cpu Switch(config-r-mc)#auto-sync standard Switch(config-r-mc)#end Switch#
NRP-1 Redundancy
Redundant first-generation NRPs use EHSA signals. These signals let the two NRPs negotiate which is the master and which is the secondary. After the NRPs determine which is the primary, they communicate that information to the NSP. The NSP then communicates with that specific NRP.
Configuring an NRP pair for redundancy starts with configuring the NSP, which is the controlling module for the Cisco 6400 UAC. Therefore, there are two sets of commands for NRP-1 redundancy:
Configure NRP-1 redundancy on the NSP:
Switch(config)#redundancy Switch(config-r)#main-cpu Switch(config-r-mc)#associate slot 1 2 (You need specify only the first slot of the redundant pair, because redundant pairs must be adjacent. The second slot is assumed to be the adjacent slot. Specifying both slots is not harmful, though.) Switch(config-r-a-sl)#prefer 1
Configure auto-sync on the primary NRP-1:
Router(config)# redundancy Router(config-r)# main-cpu Router(config-r-mc)# auto-sync standard
NSP PCMCIA Disk Protection for NRP-2
NRP-2s do not support redundancy. However, an important aspect of NSP functionality affects the NRP-2 in the case of NSP failover. Bear in mind that the NRP-2 is controlled and configured entirely through the NSP, without direct access to the NRP-2 itself, and the NRP-2 depends on the NSP for image and file storage. The NRP-2 operation is ensured during switching from a failed NSP to a working NSP through disk mirroring of the PCMCIA disks on the redundant NSPs. Introduced in Cisco IOS Software Release 12.1(5)DB, PCMCIA disk mirroring enables automatic data synchronization between the PCMCIA disks of the two redundant NSPs. Disk synchronization is the act of copying data from one disk to another.
Without disk mirroring, there is no guarantee of NRP-2 support after an NSP failover. This means that you might have to manually restore the NRP-2 state to its status before the failover. With disk mirroring enabled, NRP-2 has continued support from the NSP, except during the relatively short NSP failover period.
When PCMCIA disk mirroring is enabled, as it is by default, disk synchronization is initiated in any of the following situations:
The primary or secondary NSP boots or reloads
The secondary NSP is inserted into the Cisco 6400 chassis
A PCMCIA disk is inserted into disk slot 0 of the primary or secondary NSP
The PCMCIA disk in disk slot 0 of either NSP is formatted
A command is entered to
Re-enable disk mirroring (mirror)
Explicitly initiate disk synchronization (redundancy sync)
Modify or reorganize the files on the disks (copy, rename, delete, mkdir, format)
Cisco recommends that you use PCMCIA disks that have the same memory capacity.
PCMCIA disk mirroring is not supported in Cisco IOS Software Release 12.1(4)DB and earlier releases. Use the dir, mkdir, and copy EXEC commands to manually copy files from the primary NSP's PCMCIA disks to the secondary NSP's PCMCIA disks.
PCMCIA disk mirroring also introduced new labels for pairs of mirrored disks:
mir-disk0—PCMCIA disks in disk slot 0 of both NSPs
mir-disk1—PCMCIA disks in disk slot 1 of both NSPs
The mir-disk0 and mir-disk1 labels let you perform any integrated file system (IFS) operation (such as copy, rename, or delete) on the same file on both the primary and secondary disks.
Disk mirroring (automatic data synchronization between a pair of disks) is not supported between the following:
Two disks on a single NSP
Two disks with mismatched slot numbers (disk0: and disk1:)
You can initiate disk synchronization between disk0: and disk1: on the active NSP, even in a single-NSP system.
There are other uses for the PCMCIA disks aside from providing NRP-2 configuration redundancy. For instance, you can make full image and configuration backups if the disks are of sufficient size. Visit the appropriate online Cisco documentation for your version of Cisco IOS Software for other tips about these versatile disks.
NLC Redundancy and SONET APS
SONET APS provides a mechanism to support redundant transmission interfaces (circuits) between SONET devices. Automatic switchover from the working (primary) circuit to the protection (secondary) circuit happens when the working circuit fails or degrades.
The Cisco 6400 supports the following SONET APS operations:
1+1—There is one working interface and one protection interface, and the payload from the transmitting end is sent to both the receiving ends. The receiving end decides which interface to use. The line overhead (LOH) bytes (K1 and K2) in the SONET frame indicate both status and action.
Linear—A back-to-back connection (as opposed to a ring topology), as defined in the "Telcordia GR-253-CORE" document.
Unidirectional—Transmit and receive channels are switched independently.
Nonreverting—Nonreverting channels continue to operate after a failure has been corrected, thus preventing data from flowing back to the working channel.
Enabling and disabling SONET APS—In the Cisco 6400, a pair of redundant ports is represented as a single interface. APS commands are accepted only for an interface that represents a pair of redundant ports.
For APS operation, the APS mode must be specified for each interface associated with a redundant pair of ports. To enable SONET APS, use these commands, beginning in global configuration mode:
Switch(config)#interface atm slot/subslot/port
You can use either NLC port number, 0 or 1. When an NLC is configured for redundancy, all ports on that card are automatically configured to operate in redundant mode using SONET APS.
Switch(config-if)#aps mode linear 1+1 nonreverting unidirectional
This command enables SONET APS on the interface. This command must be entered before any other aps commands. SONET APS is enabled by default when you install an NLC in a slot already configured for redundancy. Here is an example of a configuration with redundancy:
redundancy associate slot 1 2 ! interface ATM1/0/0 no ip address no ip redirects no ip proxy-arp no atm auto-configuration no atm ilmi-keepalive atm uni version 4.0 aps mode linear 1+1 nonreverting unidirectional aps signal-fail BER threshold 3 !
If you disable the redundant NLC configuration by using the no associate slot or no associate subslot redundancy configuration command, two interface configuration sections are created, one for each port, but all the APS configuration commands are removed. Here is an example of adjacent NLCs that are operating independently, not redundantly:
interface ATM1/0/0 no ip address no ip redirects no ip proxy-arp no atm auto-configuration no atm ilmi-keepalive atm uni version 4.0 ! interface ATM2/0/0 no ip address no ip redirects no ip proxy-arp no atm auto-configuration no atm ilmi-keepalive atm uni version 4.0 !
For two full-height (OC-12/STM4) NLCs to act as a redundant pair, they must be installed in adjacent slots, such as slots 1 and 2. By default, the NLC in the lower-numbered slot is the working device, and the NLC in the higher-numbered slot is the protection device.
To configure redundant full-height NLCs, use the redundancy and associate slot commands, as in the following example, where the OC-12s in slots 5 and 6 are configured for redundancy:
! redundancy associate slot 5 6 !
For two half-height NLCs to act as a redundant pair, they must be installed in adjacent slot/subslot pairs. Here are some examples:
1/0 and 2/0, or 1/1 and 2/1
3/0 and 4/0, or 3/1 and 4/1
5/0 and 6/0, or 5/1 and 6/1
7/0 and 8/0, or 7/1 and 8/1
To configure redundant half-height NLCs, use the redundancy command as you have been doing, and use a variant of the associate slot command, associate subslot. In the following example, the OC-3s in subslots 3/0 and 4/0 are configured as a redundant pair:
! redundancy associate subslot 3/0 4/0 !
Verifying NLC Redundancy
To verify NLC redundancy, use the show aps EXEC command on the NSP. The show aps command displays the status for all NLCs configured for port redundancy:
Switch#show aps
ATM7/0/0: APS Lin NR Uni, Failure channel: Protection
Active Channel: CHANNEL7/0/0, Channel stat: Good
Port stat (w,p): (Good, Good)
ATM7/0/1: APS Lin NR Uni, Failure channel: Protection
Active Channel: CHANNEL7/0/1, Channel stat: Good
Port stat (w,p): (Good, Good)
Verifying SONET APS
To verify that SONET APS is enabled, or to determine if a switchover has occurred, use the show aps EXEC command or the show controller atm slot/subslot/port command.
In the following example, slot 7 contains the working (primary) card, and slot 8 contains the protection (secondary) card:
Switch#show aps
ATM7/0/0: APS Lin NR Uni, Failure channel: Protection
Active Channel: CHANNEL7/0/0, Channel stat: Good
Port stat (w,p): (Good, Good)
ATM7/0/1: APS Lin NR Uni, Failure channel: Protection
Active Channel: CHANNEL7/0/1, Channel stat: Good
Port stat (w,p): (Good, Good)
In the following example, the OC-3 interface ATM 5/0/0 is not configured for redundancy:
Switch#show controller atm 5/0/0 Redundancy NOT Enabled on interface IF Name: ATM5/0/0 Chip Base Address(es): A8B08000, 0 Port type: OC3 Port rate: 155 Mbps Port medium: SM Fiber Port status:Good Signal Loopback:None Flags:8308 TX Led: Traffic Pattern RX Led: Traffic Pattern TX clock source: network-derived Framing mode: sts-3c Cell payload scrambling on Sts-stream scrambling on
Setting SONET APS Priority Requests: Preventing or Causing Automatic Protection Switching
APS priority requests are used to manually control the relationship between two APS ports from EXEC mode. The APS priority levels, lockout (1), force (2), and manual (5), are defined in the "Telcordia GR-253-CORE" document.
To set the APS priority requests, use the following commands in EXEC mode:
Switch#aps lockout atm slot/subslot/port
This APS priority level 1 request prevents a working interface from switching to a protection interface.
Switch#aps force atm slot/subslot/port from [protection | working]
This APS priority level 2 request manually forces the specified interface to the protection or working interface unless a request of equal or higher priority is in effect.
Use the working option to force operation from the working channel to the protection channel. Use the protection option to force operation from the protection channel to the working channel. For instance, in the following example, the system is forced to use the protection channel associated with ATM interface 1/0/0:
Switch#aps force atm 1/0/0 from working
The following APS priority level 5 request manually switches an interface to the protection or working interface unless a request of equal or higher priority is in effect. The working and protection options are available for this command as well:
Switch#aps manual atm slot/subslot/port from [protection | working]
The Switch#aps clear atm slot/subslot/port command manually clears all posted APS priority requests created by any of the APS priority commands.
To verify that you successfully set the APS priority requests, you can use the show aps EXEC command:
Switch#aps force atm 5/1/0 from working Switch#show aps ATM5/1/0:APS Lin NR Uni, Failure channel:Working Active Channel:CHANNEL6/1/0, Channel stat:Force Switch Port stat (w,p):(Good, Good)
Setting SONET APS Signal Thresholds
You can configure the APS signal bit error rate (BER) thresholds at which the system announces signal degradation or signal failure.
The Switch(config-if)#aps signal-degrade BER threshold value command sets the interface's BER threshold value for signal degradation. This controls the BER value at which signal degradation is announced, indicating an unstable or error-prone connection. This BER threshold can be in the range of 10–5 to 10–9. There is no default threshold, although the generally accepted telecom industry standard is 10–7.
The Switch(config-if)#aps signal-fail BER threshold value command sets the interface's BER threshold value for signal failure. This controls the BER value at which a signal failure is announced, indicating a broken connection. This BER threshold can be in the range of 10–3 to 10–5, with a default threshold of 10–3.
The value argument represents the exponent of the BER threshold. For instance, a value of 5 sets the threshold to 10–5. For example, here is how to set the APS signal degradation and signal failure thresholds for ATM interface 1/0/0:
Switch(config)#interface atm 1/0/0 Switch(config-if)#aps signal-degrade BER threshold 7 Switch(config-if)#aps signal-fail BER threshold 5
Verifying SONET APS Signal Thresholds
To display an interface's current BER threshold settings, use the show interface atm command:
Switch#show interface atm 1/0/0 interface ATM1/0/0 description la1 no ip address no ip redirects no ip proxy-arp no atm auto-configuration no atm ilmi-keepalive atm uni version 4.0 aps mode linear 1+1 nonreverting unidirectional aps signal-fail BER threshold 3 aps signal-degrade BER threshold 9
Primary and Secondary Role Switching
The Cisco 6400 allows you to manually force the primary and secondary devices in a redundant pair to switch roles. This capability can be important for upgrade or debug activities.
To reverse the primary and secondary roles in redundant modules, use the following command in EXEC mode:
Switch#redundancy force-failover {slot | slot/subslot | main-cpu}
This command forces the system to switch the current primary and secondary devices of the redundant pair.
Now that you have seen the redundancy commands, you can begin configuring the 6400 to accept and manage the incoming connections at the Layer 2 and Layer 3 levels.
Configurations for ATM Switching
Here is the most basic pair of commands that direct ATM connections through the Cisco 6400. To map PVC 1/100 coming from int NLC 1/0/0 to NRP 7/0/0, where it would change identification to become PVC 1/101, the 6400 commands would be
NSP(config)#int atm 1/0/0 NSP(config-if)#atm pvc 1 100 interface atm7/0/0 1 101
NOTE
You can also use PVPs to map whole groups of individual PVCs. Just substitute pvp for pvc and leave off the virtual channel identifier after the path number.
The first step is to address the ATM interface 1/0/0. This particular NLC identifier can relate to any of the following:
A coaxial, half-height NLC (DS3 or E3) that addresses the BNC connectors on the 6400's backplane coaxial I/O board. The interface identification 1/0/0 would denote the connection in the first slot, the upper subslot, and the first of two ports for that upper subslot.
A fiber-connected, half-height NLC (OC-3 or STM1) with optical fiber connections on the front of the card. The identifier 1/0/0 would denote the first slot's upper subslot's first port.
A fiber-connected, full-height NLC (OC-12 or STM4) occupying the full first slot, obviously starting with the upper subslot, with one and only one port for the relatively large optical fiber connection on the front.
After addressing the NLC, the second command maps the VC to the ATM interface on the NRP card in slot 7/0/0 and renumbers the virtual channel identifier to 101 as it will be handled on the NRP. You can think of this mapping as across the 6400's backplane, after the NLC has stepped down the incoming high-speed signal (coaxial or optical).
Configurations for Layer 3 Terminations
After the PVC arrives at the NRP, more sophisticated coding is required to identify and manage the connection. This coding defines the Layer 3 terminations (bridging, PPPoE, PPPoA) as well as security options (AAA, RADIUS, or TACACS+) and address management options such as DHCP. Each of these is explained in the following sections with examples.
PPPoA
The following is the simple, manual configuration for a PPPoA connection on the 6400's NRP:
router(config)#username cisco password Cisco router(config)#interface atm0/0/0.1 point-to-point router(config-if)#pvc 1/101 router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-template 1 router(config-if-atm-vc)#ubr 384 router(config-if-atm-vc)#exit
The username cisco password Cisco command identifies the remote ATU-R host name (cisco) and password (Cisco) used for PPP CHAP authentication.
The interface atm0/0/0.1 point-to-point command identifies the subinterface (logical division of a physical interface) atm0/0/0 as the target interface for the incoming connection. This subinterface is a point-to-point connection.
The pvc 1/101 command addresses the connection that will terminate on this subinterface as a PVC, with the newly renumbered identification of VPI=1, VCI=101.
The encapsulation aal5mux ppp virtual-template 1 command sets the encapsulation method for the PVC 1/101 as AAL5MUX. With AAL5MUX (as opposed to AAL5SNAP), multiple protocols (such as IP and IPX) can be carried inside the PPP frames and terminated on this interface. This command line also establishes that virtual template 1 will be used for additional configuration information for this PVC. You will see shortly the virtual template's labor-saving, commonly-shared parameters.
ubr 384 is a simple command that defines the unspecified bit rate (UBR) PCR as 384 Kbps bidirectionally (both upstream and downstream). The PCR is the only parameter that can be set with UBR, and it is optional. If no PCR is defined, each connection is theoretically free to occupy all the available bandwidth.
The previous example is an example of when a single VC within a subinterface is configured for PPPoA encapsulation (AAL5MUX). Although Template 1 is used to define AAA configuration for this VC, you can see that configuring each individual VC is not the best way to conduct large-scale implementations. Still, you should learn this simplest way so that you can appreciate the shortcuts shown later in this section.
The NRP's virtual templates assign PPP features (or other architecture characteristics) to a PVC. As each PPP session comes online, a virtual-access interface is cloned from the virtual template. This virtual-access interface inherits all the configuration specified in the virtual template. When the virtual template is changed, the changes are automatically propagated to all virtual-access interfaces cloned from that particular virtual template. Here is an example of a configured virtual template:
(lines deleted) pvc 1/101 encapsulation aal5mux ppp Virtual-Template1 (lines deleted) interface virtual-template1 description PPPoATM ip unnumbered gigabit-ethernet0/0/0 peer default ip address pool dsl ppp authentication chap ! ip local pool dsl 192.168.40.20 192.168.40.50
In this configuration, it is assumed that all PPPoA VCs (DSL users) cloned from virtual template 1 will use CHAP authentication and will be allocated an IP address from the pool named dsl configured on the router. When the virtual template is changed, the changes are automatically propagated to all virtual-access interfaces cloned from that particular virtual template. To configure a different class of users on the same router, you can provision a separate virtual template interface. You can have up to 25 virtual templates.
An interesting characteristic of the virtual template is that the local end of the PPPoA connection runs without an explicitly-defined IP address. Instead, the IP address of the NRP-2's Gigabit Ethernet interface is used for addressability. This could also be the Fast Ethernet interface on the first-generation NRP or a loopback interface on either type of NRP. For reasons of memory allocation and addressing beyond the scope of this course, the virtual-access interface must have some sort of interface IP address linked with it syntactically. Therefore, this command essentially says, "Because we must link some sort of IP address to this virtual-access interface, but we do not want to waste a real IP address on it, just refer to it as having the same IP address as the already-designated Gigabit Ethernet interface."
In any case, do not use a static IP assignment within a virtual template; routing problems can occur, and you might end up working late if you forget this caution. Always use the ip unnumbered command when configuring a virtual template.
Following are explanations of the commands used:
interface virtual-template number—Associates a virtual template with a virtual template interface.
description PPPoATM—An optional plain-language description, which could also be the name of the marketed class of service, perhaps similar to "Business-class Gold" or "Residential-class Regular Plan."
ip unnumbered gigabit-ethernet 0/0/0—Enables IP on the interface without assigning a specific IP address.
no ip directed-broadcast—Depending on the Cisco IOS Software version, you might not see this command line, because it is now a default value. It is explained here only in the interest of completeness. This subcommand disables forwarding of directed broadcasts on the interface. The default is to forward directed broadcasts. A directed broadcast is a packet sent to a specific network or series of networks, whereas a flooded broadcast packet is sent to every network. A directed-broadcast address includes the network or subnet fields.
peer default ip address {pool [poolname] | dhcp }—Specifies a dynamic IP address assignment method, in this case from a named pool of IP addresses. Another option is to assign addresses from a DHCP server.
ppp authentication {pap | chap} [pap | chap]—Selects the authentication protocol, CHAP in this case, and an optional secondary protocol.
ip local pool dsl 192.168.40.20 192.168.40.50—Defines the range of 31 IP addresses available through the pool named dsl. These addresses may be reused in instant succession as soon as one host device (DSL subscriber) relinquishes an address by logging off the DSL network.
Although instructive, this method is incredibly cumbersome, because you must define each PVC in turn, defining the encapsulation type for each PVC, referring to the same virtual template for each one, and so on. And this very simple example doesn't differentiate between service levels by bit rate, and so on.
How can you reduce the manual configuration for each PVC, saving labor costs and minimizing the chance of human error? You can group characteristics in a class of parameters and then reference the class repeatedly. Here is a configuration that does just that:
router(config)#vc-class atm ppp-atm !names the type of class, in this case, an ATM Point-to-Point Protocol over ATM class! router(config-vc-class)#encapsulation aal5mux ppp virtual-template 1 router(config-vc-class)#ubr 384 router(config-vc-class)#exit router(config)#interface ATM 0/0/0 router(config-if)#class-int ppp-atm !Associates the new class with the interface ATM 0/0/0! router(config-if)#pvc 1/101 router(config-if-atm-vc)#exit router(config-if)#pvc 1/102 router(config-if-atm-vc)#exit
In this example, a virtual connection class (VC class) called PPP-ATM is defined that specifies how VCs will be encapsulated and secured. This VC class is then associated with the interface ATM0/0/0 on the NRP. Remember that ATM0/0/0 is the NRP's main (backplane) connection on the 6400. By associating the VC class with the interface, every individual PVC that is identified on that interface automatically takes on the characteristics of that class. This automation eliminates the need to repeat the characteristics line by line for each PVC.
This virtual class refers to the baseline virtual template, constituting a reference within a reference, meaning that when these VCs are assigned the values of the virtual class, they also inherit all the values of the virtual template. For instance, you already saw that the virtual template uses the PPP protocol CHAP to provide for AAA (Authentication, Authorization, and Accounting). This eliminates typing the same CHAP definitions for every PVC.
The VC class can be applied to an entire interface or subinterface, but there is still flexibility for different service levels. Even if the VC class is associated with an interface, an individual PVC on that same interface can be associated with a different VC class without affecting the overall association of the interface class for other PVCs.
It should be obvious that the VC class method of user configuration is much more efficient than repeated, individual VC configuration for large-scale service deployment. However, this method still requires manually identifying individual PVCs on a particular interface, even if no further definition is needed. Therefore, this is still a labor-intensive configuration to accommodate the tens of thousands of PVCs in a large DSL network. In the interest of working smarter, not harder, there should be a still-easier way. This easier way makes use of autodiscovery, as explained next.
This method does not require any individual definition of PVCs after they arrive on the NRP. With careful planning and precise advance configuration, the incoming PVCs are automatically switched to certain interfaces, according to the particular service levels, where the associated VC class has been associated on that interface. Here is a simple example of the basic commands to establish this autodiscovery and routing:
router(config)#vc-class atm ppp-atm router(config-vc-class)#encapsulation aal5mux ppp virtual-template 1 router(config-vc-class) #exit router(config)#interface ATM 0/0/0 router(config-if)#atm ilmi-enable router(config-if)#atm ilmi-pvc-discovery sub-interface router(config-if)#interface ATM 0/0/0.101 router(config-if)#class-int ppp-atm router(config-if) #exit
Here are the steps required for this most efficient method of handling PVCs, in their suggested order of implementation:
Step 1 The individual PVCs must be configured with ordered VPIs that correspond to the individualized service levels. This can be done at the IP DSL Switch or when mapping the PVCs across the 6400 backplane. For instance, a very robust and well-differentiated marketing plan for the DSL service provider might offer six DSL service levels: regular, fast, and fastest for both business and residential customers. Therefore, the corresponding VPIs could be numbered 101, 102, and 103 for business-class customers, and the VPIs of the residential-class customers could be numbered 201, 202, and 203. As mentioned in Appendix B, the Network-Network Interface (NNI) topology has 4096 available VPI numbers.
Step 2 You must create NRP subinterfaces that correspond to the VPI numbers. In this example, these subinterfaces would be designated as follows:
int ATM 0/0/0.101 Regular business-class service
int ATM 0/0/0.102 Fast business-class service
int ATM 0/0/0.103 Fastest business-class service
int ATM 0/0/0.201 Regular residential-class service
int ATM 0/0/0.202 Fast residential-class service
int ATM 0/0/0.203 Fastest residential-class service
Step 3 In this example, you must define six virtual classes of service, each of which might reference as few as a single virtual template, as explained earlier. For simplicity, you could name each ATM VC class according to the marketed service level.
Step 4 Following this scenario, you would associate each of the virtual classes with the matching subinterface using the int-class command. This means that each of the six subinterfaces would have associated with it a particular VC class, with parameters varying by the end user's subscription.
Step 5 The fifth and suggested last step is to enable ILMI and ilmi-pvc-discovery. ILMI is one of ATM's internal signaling and control protocols.
As PVCs arrive on the NRP's main interface, int ATM0/0/0, they are discovered by the ILMI protocol. The incoming PVC's VPI is identified and matched with a corresponding subinterface that was configured in advance. In the present scenario with six different service levels and six different subinterfaces, the PVCs whose VPI is 101 would automatically be switched to subinterface 0/0/0.101, where they would be assigned the parameters that were associated with that subinterface through the VC class. The PVCs whose VPI is 102 would automatically be funneled to the subinterface 0/0/0.102, where the group characteristics would include a medium-fast peak cell rate. The PVCs from the business-class customers who had paid for the fastest service available, those whose PVCs came into the NRP with a VPI of 103, would automatically be steered by ILMI to the subinterface of 0/0/0.103. The continuous process of autodiscovery by ILMI and the assignment of the appropriate class characteristics is simultaneous, meaning that the residential customers' PVCs are also switched to their appropriate target subinterfaces, there to assume their own characteristics.
Consider this great news: You are not required to specify any individual PVC definitions, such as encapsulation and bit rate, for these tens of thousands of incoming connections! Of course, you should carefully define the VC classes and subinterfaces in advance and then test the ILMI discovery on a few sample PVCs in advance.
As many subinterfaces may be set up as there are VPIs. For instance, all incoming PVCs whose VPI is 2 would be routed automatically to subinterface 0/0/0.2, all incoming PVCs whose VPI is 3 would be routed automatically to subinterface 0/0/0.3, and so on. Each of these subinterfaces would presumably have a unique virtual class associated with it. However, in conformance with the good practice of a limited number of profiles on the IP DSL Switch, you should not need more than a dozen different service levels, and therefore, no more than a dozen different subinterfaces. This minimizes, to almost nothing, excessive ATM overhead and processing demands that could degrade performance if you had an unrealistically high number of subinterfaces, such as a different subinterface (and service level) for every PVC.
Now that you have configured the ultra-efficient autodiscovery of PVCs on the NRP, you must know how to verify the ATM traffic's status. You can do this with the command show atm pvc ppp, which precisely displays the status of the ATM PVCs of the PPP type. Here is an example of this command's output:
NRP-1-8#sho atm pvc ppp
VCD /
ATM Int. Name VPI VCI Type VCSt VA VASt
0/0/0 17 1 34 PVC UP 13 DOWN UBR 155000 UP
0/0/0 18 1 36 PVC UP 10 UP UBR 155000 UP
0/0/0 19 1 38 PVC UP 14 DOWN UBR 155000 UP
0/0/0 6 1 40 PVC UP 8 DOWN UBR 155000 UP
0/0/0 1 1 42 PVC UP 6 DOWN UBR 155000 UP
0/0/0 5 1 44 PVC-L UP 7 DOWN UBR 155000 UP
0/0/0 8 2 36 PVC UP 9 DOWN UBR 155000 UP
0/0/0 11 3 38 PVC-M UP 11 DOWN UBR 155000 UP
0/0/0 10 3 40 PVC-L UP 12 DOWN UBR 155000 UP
0/0/0.100 14 100 100 PVC-L UP 21 DOWN UBR 155000 UP
This command also causes each PVC in turn to be analyzed in detail and reported, as shown for this single PVC:
Open: IPCP Bound to ATM4/0 VCD: 2, VPI: 0, VCI: 34 Cloned from virtual-template: 1 Last input 01:04:26, output never, output hang never Last clearing of "show interface" counters 5d02h Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 782 packets input, 30414 bytes, 0 no buffer Received 3 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 395 packets output, 5540 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions NRP-1-8#
In this output, the router first displays the status of all PVCs configured for PPP in the ATM interface. The name of the VC, the VC VPI/VCI, the VC state (up/down, and the Virtual Access (VA) number are displayed, along with VA interface-specific configuration and status. Then the second portion (which shows only one PVC to avoid repetition) provides quick insight into the status of a particular PVC.
Overall, the show atm pvc ppp command's details might vary with the Cisco IOS Software version, so you should consult the particular version's release notes for full details of the columns.
Along with configuring the PVC mapping and verifying PVCs as needed, you also need to configure options for IP address management (DHCP) and security (AAA, RADIUS), as shown in the next section.
Configuring DHCP, AAA, and RADIUS
How can you configure the IP address allocation scheme, as well as security, which are required for PPPoA and the other, sophisticated topologies on the 6400?
To enable DHCP on the NRP, you can use this command set:
router(config)#ip dhcp-server <server name/ip> !the DHCP server IP address is the variable at the end of this line! router(config)#interface virtual template-template 2 router(config-if)#ip unnumbered ethernet 1/0 !this is the management Ethernet port to be used as the address for the virtual template; this is also called the Backplane Ethernet (BPE)! router(config-if)#peer default ip address dhcp router(config-if)#ppp authentication chap
In this example, a DHCP server location (by IP address) and authentication method (CHAP) are defined under a virtual template (virtual template 2). The virtual template is then associated with a VC during the VC configuration process. Notice that the virtual template takes the address of the management Ethernet port. This is usually the next-hop gateway router address assigned to the CPE router during authentication.
Large-scale deployment of PPP user services requires the use of a central database such as RADIUS to ease the configuration burden. RADIUS servers, providing AAA functionality, contain the per-user configuration database, including password authentication and authorization information. To enable the functionality of AAA and define the application of the RADIUS protocol on the NRP, you can use the global config command set here:
aaa new-model aaa authentication login default radius aaa authentication ppp default radius aaa authorization network radius radius-server host 192.168.1.1 auth-port 1645 acct-port 1646 !These are the standard authentication and accounting ports for the RADIUS daemon! radius-server timeout 20 !measure in seconds! radius-server key root !the word root is the shared key between the Network Access Server (NAS) and the RADIUS server! aaa new-model aaa authentication login default none aaa authentication ppp default local group radius aaa authorization network default local group radius none aaa accounting network default wait-start group radius ! username cisco password 0 cisco ! interface ATM0/0/0.132 point-to-point pvc 1/32 encapsulation aal5mux ! interface Virtual-Template1 ip unnumbered FastEthernet0/0/0 peer default ip address pool dsl-pool ppp authentication chap ! radius-server host 192.168.2.20 auth-port 1645 acct-port 1646 radius-server key cisco
Following are the explanations for the pertinent commands:
aaa new-model—Enables the AAA access control model.
aaa authentication login default none—Ensures that if the user cannot be authenticated with the various methods defined in the next command, there is no default login. (All users must be authenticated according to at least one defined method.)
aaa authentication ppp {default | list-name} method1 [method2...]—Specifies one or more AAA authentication methods for use on interfaces running PPP. The list-name option refers to the name of this particular method list (or the default list, as in the previous example), and the method option is a list of methods to be tried in turn. You can use the command aaa authentication ppp with the method keyword local to specify that the Cisco router or access server should use the local username database for authentication. In this case, the local username database is used first, and then RADIUS.
The aaa authorization network radius command sets RADIUS for network authorization, address assignment, and access lists. It follows the order of methods defined for individual PPP login.
You can further control access and accounting by using the wait-start keyword, which ensures that the RADIUS security server acknowledges the start notice before granting the user's process request. In this case, it is applied only to network activities. To stop all accounting activities on this line or interface, use the none keyword.
The RADIUS-specific commands in the second half of the configuration are as follows:
radius-server host {hostname | ip-address} [auth-port port-number][acct-port port-number]—Specifies a RADIUS server host.
radius-server key cisco—Sets the encryption key to match that used on the RADIUS server—in this case, the keyword cisco.
The AAA and RADIUS commands also apply to PPPoE, which is discussed in the next section.
PPPoE
As you learned in Chapter 3, PPPoE requires a PPP software client at the user location. The client (either the desktop PC or the Cisco 820 series router) initiates a PPP session by encapsulating PPP frames into a MAC frame and then bridging the frame (over ATM/DSL) to the gateway router. From this point, PPP sessions can be established, authenticated, addressed, and so on. VCs and associated PPP sessions can also be associated with VPDN groups, as shown here:
NRP-1(config)#username cisco password 0 cisco NRP-1(config)#vpdn enable NRP-1(config)#vpdn-group 1 NRP-1(config-vpdn)#accept dialin NRP-1(config-vpdn)#protocol pppoe NRP-1(config-vpdn)#virtual-template 1 NRP-1(config-vpdn)#pppoe limit per-vc 20 NRP-1(config)#int virtual-template 4 NRP-1(config-if)#ip unnumbered FastEthernet0/0/0 NRP-1(config-if)#ip mtu 1492 NRP-1(config-if)#peer default ip address pool pppoe-pool NRP-1(config-if)#ppp authentication chap NRP-1(config)#ip local pool pppoe-pool 192.168.5.100 192.168.5.150 NRP-1(config)#int atm 0/0/0.143 point-to-point NRP-1(config-subif)# NRP-1(config-subif)#pvc 3/143 NRP-1(config-if-atm-vc)#encapsulation aal5snap NRP-1(config-if-atm-vc)#protocol pppoe ip cef !
In this example, the username and password (both cisco) are defined in the first line.
The following PPPoE termination command sets up VPDN:
vpdn enable
The following defines the VPDN group:
pppoe limit per-vc number
The command vpdn-group 1 identifies the particular VPDN group whose characteristics follow. The command accept dialin configures the router to accept dial-in calls. The command protocol pppoe defines the VPDN's protocol as PPPoE. The command virtual-template 1 associates this VPDN group with a particular virtual template, which is quite like the virtual template you created and referenced for PPPoA in the previous section. The optional command pppoe limit per-vc 20 limits the number of PPPoE sessions that can be established on a virtual circuit. This limitation is a great help in managing the licensing of user accounts. The default is 100 sessions per VC.
Notice that the encapsulation type is aal5snap. This is the standard for both PPPoE and bridging.
The interface virtual-template number command selects the virtual-access interface to be configured.
The ip unnumbered fastethernet 0/0/0 command enables IP on the interface without specifying a new address. In this case, the only address that might be associated with this virtual-template interface is the one already defined for the Fast Ethernet interface.
The ip mtu 1492 command sets the IP MTU size to 1492, which is required for PPPoE.
The peer default ip address pool pppoe-pool command specifies that the dynamic IP addresses will come from the pool called pppoe-pool. Notice that the range of IP addresses in this pool, 51 in all, is defined in the following authentication definition line:
ppp authentication chap
This command sets the authentication protocol.
The NRP-1(config)#interface ATM0/0/0.143 point-to-point command defines a subinterface of the point-to-point type.
The NRP-1(config-subif)# subcommand disables the forwarding of directed broadcasts on the interface. The default is to forward directed broadcasts. A directed broadcast is a packet sent to a specific network or series of networks, whereas a flooded broadcast packet is sent to every network. A directed-broadcast address includes the network or subnet fields.
The NRP-1(config-subif)#pvc 3/143 command defines a PVC on the subinterface.
The NRP-1(config-if-atm-vc)#encapsulation aal5snap command defines the type of encapsulation for PVC 3/143 as aal5snap, which is required for PPPoE (and RFC 2684 bridging as well, as you will see in the next section).
The command NRP-1(config-if-atm-vc)#protocol pppoe explicitly defines the protocol type as PPPoE, which avoids confusion with the much simpler bridging type of PVC, which is also based on RFC 2684.
The ip cef command enables Cisco Express Forwarding (CEF), because CEF is required for PPPoE.
This concludes the explanation of PPPoE on the Cisco 6400's node route processor.
RFC 2684 Bridging
This simplest type of architecture is frequently found in legacy DSL networks. It requires setting up a translation between the bridged network, the DSL users themselves, and the larger routed network, the Internet outside the local service area. This translation on the NRP is a bridge group virtual interface, meaning that you arbitrarily convert one of the Layer 3 interfaces to a Layer 2 bridging interface on the NRP. Here is an example of the configuration required:
router(config)#bridge irb router(config)#bridge 1 route ip router(config)#interface atm0/0/0.1 point-to-point router(config-subif)#bridge-group 1 router(config-subif)#pvc 10/101 router(config-if-atm-vc)#encapsulation aal5snap router(config-if-atm-vc)#ubr 384 router(config-if-atm-vc)#protocol bridge broadcast router(config-if-atm-vc)#exit router(config)#bridge 1 protocol ieee router(config)#int bvi 1 router(config-if)#ip add 192.168.1.1 255.255.255.0
The following are explanations of the commands used in this example:
(config)#bridge irb—Defines IRB. Usually for general Internet access, bridging may be combined with IRB to terminate the bridged traffic and route the traffic to an IP or IPX network. Issuing the bridge irb command enables the IRB feature in IOS, but you still need to specify the protocol to be used from the bridged domain to the routed domain. That is the result of the bridge 1 route ip command. When you configure bridge 1 route ip, a BVI is created. The BVI number corresponds to the bridge group. All other protocols are bridged. You can also route multiple protocols over a BVI.
(config)#interface atm0/0/0.1 point-to-point—Defines a subinterface and specifies that it is a point-to-point type.
(config-if)#bridge-group 1—Associates bridge group 1 with the subinterface.
(config-if)#pvc 10/101—Creates a PVC on the subinterface.
router(config-if-atm-vc)#encapsulation aal5snap—Defines the encapsulation type for this PVC as aal5snap, the same as for PPPoE.
router(config-if-atm-vc)#ubr 384—(Optional) Sets the peak cell rate for this UBR connection at 384 Kbps or any other reasonable value.
router(config-if-atm-vc)#exit—Exits PVC configuration mode.
Router(config)#bridge 1 protocol ieee—Sets the Spanning Tree Protocol type as ieee, which is by far the most common type.
(config)#interface bvi 1—Opens interface configuration mode, allowing you to define an IP address in the next line. When you intend to bridge and route a given protocol in the same bridge group, you must configure the network-layer attributes (Layer 3) of the protocol on the BVI. Do not configure protocol attributes on the BVIs. No bridging attributes can be configured on them.
Although it is generally the case that all bridged segments belonging to a bridge group are represented as a single segment or network to the routing protocol, there are situations in which several individual networks coexist within the same bridged segment. To make it possible for the routed domain to learn about the other networks behind the BVI, configure a secondary address on the BVI to add the corresponding network to the routing process.
A more-scalable and less-insecure form of RFC 2684 bridging is available—RBE. Configuring the 6400's NRP for RBE is requires only the addition of the command atm route-bridged to the PVC's definition. As you can see in the following, you also might need to define host routes if you use unnumbered interfaces:
(config)#interface ATM0/0/0.133 point-to-point ip unnumbered Loopback0 atm route-bridged ip pvc 1/33 encapsulation aal5snap ! only need host routes when using unnumbered interfaces ip route 172.168.1.2 255.255.255.255 ATM0/0/0.132 ip route 172.168.1.3 255.255.255.255 ATM0/0/0.133
This concludes the discussion of terminating PVCs with RFC 2684 bridging on the 6400's NRP.
VPN Configurations on the Cisco 6400
Configuring a virtual private network on the 6400's NRP requires more work outside the DSL network, and the 6400 itself, than any of the other architecture types. Although configuring the other end of the tunnel is far beyond the DSL network configuration, you have the opportunity now to learn these important procedures.
First, you should review these terms related to VPN:
Tunnel—A virtual pipe between the LAC and the LNS that carries multiple PPP sessions. It consists of user traffic and header information necessary to support the tunnel. The tunnel profile can be in the local router configuration or on a remote RADIUS server.
L2TP access concentrator (LAC)—The client directly connects to the LAC, which resides between the home network (Cisco in this example) and the remote user. Its job is to tunnel PPP frames through the Internet to the local L2TP network server (LNS). It may tunnel any protocol carried within PPP. The LAC initiates incoming calls and receives outgoing calls. For our examples, the LAC is typically the Cisco 6400's NRP.
L2TP network server (LNS)—The termination point for the L2TP tunnel where the home LAN is located. It is the home LAN's access point where PPP frames are processed and passed to higher-layer protocols. An LNS can operate on any platform capable of PPP termination. The LNS handles the server side of the L2TP protocol, although it can initiate the outgoing call to create a tunnel.
Session—A single tunneled PPP session. Also referred to as a call.
AAA—The authentication, authorization, and accounting server, used to store domain and user information. At the LAC, the AAA server stores domain information necessary to identify and establish the tunnel to the remote LNS. At the LNS, the AAA server stores user information needed to authenticate the tunnel user.
L2TP can support either PPPoA or PPPoE encapsulation on the PVC coming from the CPE. The LAC accepts this PPP session and establishes the L2TP tunnel to the LNS. After Link Control Protocol (LCP) has been negotiated, the LAC partially authenticates the end user with CHAP or PAP but does not process PPP packets. The user is authenticated on the LNS where the call terminates. Information necessary to identify the remote LNS can be stored in the AAA server or can be entered directly into the LAC's configuration.
The username@domain name is used to verify that the user is a VPDN client and to provide a mapping to a specific endpoint LNS. The tunnel endpoints (LAC and LNS) authenticate each other, and the tunnel opens. As soon as the tunnel exists, an L2TP session is created for the end user. The LAC propagates the LCP negotiated options and the partially authenticated CHAP/PAP information to the LNS.
L2TP utilizes two types of messages—control messages and data messages. Control messages are used to establish, maintain, and clear a tunnel and to set up and clear sessions. Data messages are used to encapsulate PPP frames being carried over the tunnel.
L2TP guarantees the delivery of control messages through a control channel. Messages in the control channel have sequence numbers used to detect loss or out-of-order delivery. Lost control messages are retransmitted. Data messages may also use sequence numbers to reorder packets and detect lost packets.
To begin configuring VPDN, follow these steps:
Step 1 Start with configuring authentication for the L2TP tunnel. This causes the LAC to check for tunnel authentication using either a RADIUS server or a local database. To use local authorization, a local database of usernames and passwords can be defined on the LAC.
Step 2 Enable VPDN with the command vpdn enable. This extends remote access to a private network across a shared infrastructure, such as the Internet.
Step 3 Define a VPDN group, as you did earlier with PPPoE. You apply all VPDN attributes for the LAC through this group. You can use the command vpdn-group number. This VPDN group contains attributes for initiating the L2TP tunnel on the LAC. Typically, you need one VPDN group for each LAC. For an LNS that services many LACs, the configuration can become cumbersome. However, you can use the default VPDN group configuration if all the LACs will share the same tunnel attributes. An example of this scenario is an LNS that services a large department with many Windows NT L2TP clients that are colocated with the LAC. Each of the Windows NT devices is an L2TP client as well as a LAC. Each of these devices demands a tunnel to the LNS. If all the tunnels will share the same tunnel attributes, you can use a default VPDN group configuration, which simplifies the configuration process.
Step 4 Enable the LAC to initiate the L2TP tunnels using the initiate-to command. The configuration looks like this:
(config)#vpdn-group 2 request-dialin protocol l2tp domain Cisco.com initiate-to ip 192.168.2.2 local name NRP-2 l2tp tunnel password 7 060506324F41In this example, the LAC is configured to initiate an L2TP tunnel to the LNS (whose IP address is 192.168.2.2) if the login contains the Cisco.com domain name. The LAC local host name and the shared secret password used for tunnel authentication between the LAC and the LNS can also be configured under the VPDN group.
Step 5 Move to the LNS and duplicate the security definitions, username, and password, as you did in Step 1 for the LAC.
Step 6 The next step on the LNS is to enable VPDN, again duplicating what you did on the LAC. You should also define a VPDN group to which you will apply all VPDN attributes for the LNS. This VPDN group contains attributes for accepting the L2TP tunnel on the LNS.
Step 7 Enable the LNS to accept L2TP tunnels, using the terminate-from command, as shown in the following, along with the other commands:
(config)#vpdn-group team1 accept-dialin protocol l2tp virtual-template 1 terminate-from hostname NRP-2 l2tp tunnel password 7 0822455D0The command accept-dialin specifies the local name to use for authenticating and the virtual template to use for cloning new virtual-access interfaces when an incoming L2TP tunnel connection is requested from a specific peer.
The command terminate-from hostname NRP-2 defines the attributes needed to find the LNS for the given domain name. You can enter the LNS's IP address, or in this case, a predefined host name (NRP-2) instead of the IP address.
In the example, the LNS is configured to accept an L2TP tunnel from the LAC with a host name of NRP-2. The shared secret password used for tunnel authentication between the LAC and the LNS can also be configured under the vpdn-group. The virtual-template 1 interface is used for creating the virtual-access interface.
Step 8 A final task on the LNS, although not necessarily performed in strict order, is to define the virtual-template interface and an IP address pool for dynamic IP address assignment over IPCP, as shown in the following:
interface Virtual-Template1 ip address 192.168.7.1 255.255.255.0 peer default ip address pool L2TP_pool ppp authentication chap ip local pool L2TP_pool 192.168.7.100 192.168.7.120You may continue to configure the virtual template interface with configuration parameters you want applied to the virtual-access interfaces.
Now that you have configured the LAC and LNS, you can use the show vpdn command to display information about active tunnels and message identifiers in a VPDN. Here is an example of the output:
lac1#show vpdn L2TP Tunnel and Session Information Total tunnels 1 sessions 1 LocID RemID Remote Name State Remote Address Port Sessions 11984 36217 ciscoemp est 172.30.248.10 1701 1 LocID RemID TunID Intf Username State LastChg Fastswitch 9 5 11984 Vi6 joe@cisco.com est 00:31:39 enabled %No active L2F tunnels %No active PPPoE tunnels
This concludes the explanation of configuring L2TP on the Cisco 6400 and other devices in the larger network.