|
|
This chapter discusses the initial configuration of the LightStream 1010 ATM switch. Because the LightStream 1010 offers true plug-and-play operation, most users may not need to perform any of these procedures.
The LightStream 1010 is shipped with the ATM address autoconfigured to an address assigned by Cisco Systems. This allows the switch to automatically configure attached end-systems using the ILMI protocol and to automatically establish itself as a node in a single-level PNNI routing domain.
The ILMI and PNNI protocols, when used with such IP address autoconfiguration mechanisms as BOOTP, allow the LightStream 1010 to be entirely self-configured. Through network management applications and the text-based command line interface (CLI), the switch's network operator will have the capability, if desired, to configure and customize all aspects of the operation of the switch.
An IP address must be assigned to allow up to eight simultaneous Telnet sessions to connect to the switch or to use SNMP network management for the switch. The Ethernet IP address can be assigned either manually or by a BOOTP server. See the section "Configure IP Interface Parameters."
Note If your Telnet station or SNMP network management workstation is on a different network from the switch, a static routing table entry must also be added to the routing table. Use the ip route command to set the static routing table entry.
For definitions of all commands discussed in this chapter, refer to the publication LightStream 1010 ATM Switch Command Reference.
The following sections describe the LightStream 1010 initial configuration:
If you want to configure some additional features, you might need the following information before you can begin your LightStream 1010 configuration:
To help configure your switch you should have already completed the worksheets in the section "Port Configuration Worksheets" in the appendix "Configuration Worksheets."
When you first power up your console and LightStream 1010, a screen similar to the following appears:
The first section of the script displays the banner information, including the software version.
The next portion of the script lists installed hardware configuration.
The LightStream 1010 should be operating correctly and transferring data.
Note If an rommon > prompt appears your switch requires a manual boot to recover. See the section "Manually Boot from Flash memory" in the chapter "Loading System Images, Software Images, and Configuration Files."
The LightStream 1010 Ethernet IP address can automatically be assigned using the BOOTP protocol by adding the MAC and IP addresses of the Ethernet port to the BOOTP server configuration file. When the switch boots, it automatically retrieves the IP address from the BOOTP server.
The switch performs a BOOTP request only if the current IP address is set to 0.0.0.0. (This is the default for a new switch or a switch that has had its configuration file cleared using the erase startup-config command.)
To allow your LightStream 1010 to retrieve its IP address from a BOOTP server, you must first determine the MAC address of the switch and add that MAC address to the BOOTP configuration file on the BOOTP server. The following tasks provide an example of creating a BOOTP server configuration file:
| Task | Command |
|---|---|
Install the BOOTP server code on the workstation, if it is not already installed. |
|
Add an entry in the BOOTP configuration file (usually /usr/etc/bootptab) for each switch. Press Return after each entry to create a blank line between each entry. Figure 4-1 is an example of a server BOOTP configuration file. |
|
Restart the LightStream 1010 to automatically request the IP address from the BOOTP server. |
Figure 4-1 is an example of a BOOTP configuration file with the LightStream 1010 ATM switch entry added at the end of the example.
The Lightstream 1010 ATM Switch is autoconfigured with an ATM address using a hierarchical addressing model similar to the OSI network service access point (NSAP) addresses. PNNI uses this hierarchy to construct ATM peer groups. ILMI uses the first 13 bytes of this address as the switch prefix that it registers with end systems.
Note The most important rule in the addressing scheme is to maintain the uniqueness of the address across very large networks.
During the initial startup the LightStream 1010 generates an ATM address using the defaults shown in Figure 4-2:
Note This first 13 bytes of the address is a switch prefix used by ILMI in assigning addresses to end stations connected to UNI ports.
Note Both MAC address fields are the same but they may not be the same as the address on the chassis label.
Using the default address format has the following features and implications:
To configure a new ATM address that replaces the previous ATM address, when running IISP software only, see the section "Configure the ATM Address" in the chapter "Configuring ILMI."
To configure a new ATM address that replaces the previous ATM address and generates a new PNNI node ID and peer group ID, see the section "Configure PNNI Node" in the chapter "Configuring ATM Routing and PNNI."
Multiple addresses can be configured for a single switch and this configuration can be used during ATM address migration. ILMI registers end systems with multiple prefixes during this period until an old address is removed. PNNI automatically summarizes all of the switch prefixes in its reachable address advertisement.
If operation with ATM addresses other than the autoconfigured ATM address is desired, use the atm address command to manually assign a 20-byte ATM address to the switch. The atm address command address_template variable can be a full 20-byte address or a 13-byte prefix followed by ellipsis (...). Entering the ellipsis will automatically add one of the switch's 6-byte MAC addresses in the ESI portion and 0 in the selector portion of the address.
| Caution ATM addressing may lead to conflicts if not configured correctly. The correct address must always be present. For instance, if you are configuring a new ATM address, the old one must be completely removed from the configuration. |
When the switch is powered on initially without any previous configuration data, the ATM interfaces are automatically configured on the physical ports. ILMI and the physical card type are used to automatically derive the ATM interface type, UNI version, maximum VPI and VCI bits, ATM interface side, and ATM UNI type. See the chapter "Configuring Port Adapter Modules Interfaces" for the interface default configuration and modification procedures.
You can accept the default ATM interface configuration or overwrite the default interface configuration.using the command line interface commands. These commands are described in the section "Configuring Virtual Connections."
This section describes modifying an ATM interface from the default configuration listed in the chapter "Configuring Port Adapter Modules Interfaces." You can accept the ATM interface configuration or overwrite the default interface configuration using the command line interface commands. These commands are described in the chapter "Configuring Virtual Connections."
The following example describes modifying an OC3 interface from the default settings to the following:
To change the configuration of the example interface, use the following EXEC commands. Use the no form of this command to disable:
| Task | Command |
|---|---|
At the privileged EXEC prompt, enter configuration mode from the terminal. |
|
| 1This command is documented in the LightStream 1010 ATM Switch Command Reference publication. |
The following example disables cell-payload scrambling and STS-stream scrambling and changes the SONET mode of operation to SDH/STM-1 of OC3 physical interface 0/0/0:
To change any of the other physical interface default configurations refer to the commands in the LightStream 1010 ATM Switch Command Reference for detailed command syntax information.
Use show controller and show running-config Commands to Display the Interface Physical Layer Configuration.
To display the physical interface configuration, use the following commands:
| Task | Command |
|---|---|
The following example displays the OC3 physical interface configuration after modification of the defaults using the show controllers command:
The following example displays the OC3 physical layer scrambling configuration after modification of the defaults using the show running-config command:
IP addresses may be configured on the LightStream 1010 ASP interfaces. Each IP address is configured using one of the following purposes:
Configure the interface to communicate with the switch Ethernet interface 2/0/0 using the following information as a guide:
Provide the IP address and subnet mask bits for the interface as follows:
Internet addresses are 32-bit values assigned to hosts that use the IP protocols. These addresses are in dotted decimal format (four decimal numbers separated by periods) such as 192.17.5.100. Each number is an 8-bit value between 0 and 255. The following is a summary of IP addressing concepts for those who are somewhat familiar with IP addressing.
The addresses are divided into three classes; the classes differ in the number of bits allocated to the network and host portions of the address.
The Class A Internet address format allocates the highest 8 bits to the network field and sets the highest-order bit to 0 (zero). The remaining 24 bits form the host field.
The Class B Internet address allocates the highest 16 bits to the network field and sets the two highest-order bits to 1, 0. The remaining 16 bits form the host field.
The Class C Internet address allocates the highest 24 bits to the network field and sets the three highest-order bits to 1, 1, 0. The remaining 8 bits form the host field.
Action: Enter your Internet address in dotted decimal format for each interface you plan to configure.
Subnetting is an extension of the Internet addressing scheme, which allows multiple physical networks to exist within a single Class A, B, or C network. The usual practice is to use a few of the far left bits in the host portion of the network address for a subnet field. The subnet mask determines whether subnetting is in effect on a network.
Internet addressing conventions allow a total of 24 host bits for Class A addresses, a total of 16 host bits for Class B addresses, and a total of 8 host bits for Class C addresses. When you are further subdividing your network (that is, subnetting your network), the number of host addressing bits is divided between subnetting bits and actual host address bits. You must specify a minimum of two host address bits, or the subnetwork is not populated by hosts.
Table 4-1 Summary of Subnetting Parameters
| First Class | First Byte | Network Bits | Host Bits | |
|---|---|---|---|---|
| Max Subnet Bits | Min Address Bits | |||
Note Because all zeros in the host field specifies the entire network, subnetting with subnet address 0 is illegal and is strongly discouraged.
Define subnet mask bits as a decimal number between 0 and 22 for Class A addresses, 0 and 14 for Class B addresses, or 0 and 6 for Class C addresses. Do not specify 1 as the number of bits for the subnet field. That specification is reserved by Internet conventions.
To configure the IP address, perform the following tasks in interface configuration mode. Use the no form of these commands to assign the default value:
| Task | Command |
|---|---|
At the privileged EXEC prompt, enter configuration mode from the terminal. |
|
| 1These commands are documented in the LightStream 1010 ATM Switch Command Reference publication. |
The following example configures the Ethernet CPU interface 2/0/0 with IP address 172.20.40.93 and subnetwork mask 255.255.255.0:
To display the IP address configuration, perform the following task in user EXEC mode:
The following example uses the show interface ethernet 2/0/0 command to display the CPU IP address:
The following example uses the show running-config command to display the CPU IP address:
This section describes network clocking, and network clocking configuration of the LightStream 1010 ATM switch.
Each port has a transmit clock and a derives its receive clock from the receive data.
Transmit clocking may be configured for each port in one of the following ways:
Derived clocking is received, along with data, from a specified interface. For example, in Figure 4-3 the transmit-clocking, configured as priority one, it is extracted from the data received at interface 0/0/0 and distributed as the transmit clock to the rest of the switch through the backplane. Interface 4/0/0 is configured to use network-derived transmit clocking which it receives across the backplane from interface 0/0/0.
Since the port providing network clock source could fail the Cisco IOS provides the ability to configure additional interfaces as clock sources, with priorities one to four.
If the network clock source interface goes down the software will switch to the next highest-configured priority network clock source. For example, in Figure 4-4 the following happens:
Note If no functioning network clock source port exists at a given time, the system clock on the ASP is used as the default clock source.
Network clocking configuration is described in the following sections:
To configure the network clocking priorities and sources, use the following EXEC commands. Use the no form of this command to disable
| Task | Command |
|---|---|
At the privileged EXEC prompt, enter configuration mode from the terminal. |
|
network-clock-select priority {atm | cbr } card/sub_card/port |
| 1This command is documented in the LightStream 1010 ATM Switch Command Reference publication. |
network clocking priorities and sources.
The following example configures interface 0/0/0, see of Figure 4-3, as the highest-priority clock source to receive the network clocking:
To configure where an interface receives its transmit clocking, use the following EXEC commands. Use the no form of this command to disable
| Task | Command |
|---|---|
At the privileged EXEC prompt, enter configuration mode from the terminal. |
|
| 1This command is documented in the LightStream 1010 ATM Switch Command Reference publication. |
network clocking on an interface.
The following example configures ATM interface 4/0/0 to receive its transmit clocking from a network derived source:
To show the switch network clocking configuration use the following commands:
| Task | Command |
|---|---|
The following example displays the switch clock source configuration of Figure 4-3:
The following example displays the clock source configuration of ATM interface 4/0/0:
Circuit emulation services-interworking functions (CES-IWF) and constant bit rate (CBR) traffic relate to a quality of service (QOS) classification defined by the ATM Forum for Class A (AAL1) traffic in ATM networks. In general, Class A traffic pertains to voice and video transmissions.
In an LS1010 environment, CBR refers to a particular class of traffic that is generated by edge (source) devices and propagated into ATM networks for transmission to other edge (destination) devices in the network. Each CBR edge device communicating in this manner must be driven by a clocking signal of identical frequency, since this signal controls the rate of CBR data insertion into the network, as well as the rate of extraction of CBR data from the network
If the clock frequency is not the same at both the ingress and egress nodes of the circuit, the data queues and buffers in the network will either overflow or underflow, resulting in periodic line errors.
The CES modules have been designed specifically to handle CBR traffic in an ATM networking environment. To provide requisite timing functions in support of CES operations, you can specify any one of three clocking modes:
However, to support synchronous clocking or SRTS clocking in your LS1010 operating environment, your network must incorporate the following facilities:
This clock distribution service enables you to distribute a PRS to, or by means of, the following network entities:
There are many considerations in planning, designing, and implementing an ATM network. Such considerations may include, but are not limited to, the specific hardware to be used in the network, the purposes to be served by the network, the protocols to be implemented within the network, and the physical topology of the network.
Among these important considerations is how a clocking signal should be distributed within the network. In all cases, the purpose of distributing a clocking signal within the network is to ensure that each constant bit rate device has access to a common reference clocking signal for synchronizing CBR data transport.
For this reason, planning for distributing a timing signal must be done on a per-chassis basis. This planning must also include a means for distributing up to three alternative clocking signals, in the event of failure of the primary clock signal. Thus, you can think of network clocking in general as a kind of "protocol" to be implemented in the network.
In summary, for the reasons outlined above, network administrators must make provision beforehand for the following:
Once these network clocking facilities are established and operational, they tend to remain static until the primary clock is lost for any reason. In this case, network clocking is dynamic in the sense that an alternate clocking signal must be placed into effect immediately, in order for the network to remain operational.
As noted in the preceding section, network clock signal distribution in an ATM network is not a trivial consideration. The task of determining a network clocking source and designing a distribution topology for the clocking signal is a task best left to network designers, planners, and engineers.
The information provided herein relative to network timing services is intended only as a general introduction to the subject for readers who may be unfamiliar with the topic, but who could profit from some knowledge of such services as they pertain to CBR data transport.
Accordingly, this document is limited to a description of the means provided to LS1010 users for selecting a clock source and defining its priority relative to other alternative clocking sources that may be available within the network.
For purposes of this document, it is sufficient to say that an LS1010 chassis derives a network clocking signal from a particular port in the chassis that has been configured to receive such a signal from a clock source available within the networking environment.
The port that you have designated to receive the clocking signal then distributes it within the LS1010 chassis to all other ports that require such a clocking signal for synchronizing CBR data transport.
In many cases, using a clocking signal from a telephone company is the simplest and best solution for a stable and reliable clocking signal, especially in those instances where you are already using a CES circuit to interconnect telephone equipment.
For example, to meet its own need for internal consistency, a telephone company typically distributes a timing signal to govern its own networking operations. Therefore, the telephone company has already addressed timing requirements similar to those that an LS1010 user must address in relation to their own CES operations. Consequently, a PBX can serve as a ready means for providing a timing signal to any user CBR device.
An LS1010 network administrator can define up to four clocking signal sources per chassis, assigning a priority to each one. Under normal operating conditions, the priority 1 signal serves as the primary clocking signal. The remaining signal sources are listed in priority order for backup purposes in the event of failure of the primary (priority 1) clock.
The clock sources configured for a CES module are revertive. For example, assume that a clock of lower priority is currently in effect due to failure of a higher priority clock source. When the higher priority clock is again restored to service for at least one minute, the system automatically reverts to this signal for network clock synchronization purposes.
To make use of network timing services in an LS1010 chassis, the user need only define the port from which a network timing signal is to be taken, and list the alternative clock sources for the port in the same order of priority as specified for the network at large.
You can accomplish these clock configuration tasks by issuing the CLI network-clock-select command, as described in the section entitled "Configuring Network Clock Priorities and Sources."
A PRS from one of the following sources is often the timing signal of choice, because such signals from major carriers are known to be highly stable, reliable, and accurate:
For CES operations, as noted earlier, three clocking modes can be used in conjunction with any CES module. These clocking modes are described briefly below, in their recommended order of consideration and use:
First, this clocking mode is the only one that supports full CES functionality. SRTS and adaptive clocking do not support structured CES services. For these reasons, synchronous clocking is the default clocking mode for all CES services.
Second, synchronous clocking exhibits superior stability, reliability, and wander/jitter characteristics.
Third, synchronous clocking is typically used in public telephony systems, making a precision reference signal readily and widely available for synchronizing CBR data transport.
This clocking mode is described in greater detail in a later section entitled "Synchronous Clocking."
This mode allows user equipment at the edges of an ATM network to use a clocking signal that is different (and completely independent) from the clocking signal being used in the ATM network proper.
For example, user equipment at the edges of the network can be driven by clock A, while the devices within the ATM network are being driven by clock B. The SRTS clocking mode enables these different timing signals to be reconciled in the course of CBR data transport through the ATM network.
This clocking mode is described in greater detail in a later section entitled "Synchronous Residual Time Stamp (SRTS) Clocking."
Although this clocking mode is the simplest and easiest to implement in an ATM network, it exhibits the poorest wander and jitter performance of all the available clocking modes. Therefore, its use is not recommended, except in instances where a PRS and network clock synchronization services are not available.
The term adaptive clocking derives from the fact that the rate at which CBR data is propagated through an ATM network is driven essentially by the rate at which such data is introduced into the network by the user's edge equipment.
For example, adaptive clocking in a CES module infers appropriate timing for data transport by calculating an "average" data rate upon arrival and conveying that data to the output port of the module at an equivalent rate.
For this reason, the actual rate of CBR data flow through the network may "wax and wane" from time to time during adaptive clocking, depending on how rapidly (or how slowly) CBR data is being introduced into the network.
Nevertheless, CBR data transport through the network occurs in a "pseudo synchronous" manner that ensures the integrity of the data.
This clocking mode is described in greater detail in a later section entitled "Adaptive Clocking."
Any module in an LS1010 chassis that is capable of receiving and distributing a network timing signal can propagate that signal to any similarly capable module in the chassis.
By issuing the CLI network-clock-select command with appropriate parameters, you can define a particular port in an LS1010 chassis to serve as the source of a PRS for the entire chassis or for other devices in the networking environment. The use of this CLI command is described in the section entitled "Configuring Network Clock Priorities and Sources."
In effect, through the network-clock-select command, you can designate a particular port in an LS1010 chassis to serve as a "master clock" source in distributing a single clocking signal throughout the chassis or to other network devices. Hence, this reference signal can be distributed wherever needed in the network to globally synchronize the flow of CBR data.
The following LS1010 modules are capable of receiving and distributing a primary reference signal (PRS):
The following sections describe the clocking modes in greater detail, presenting them in the preferred order of use in your LS1010 environment.
When equipped with a CES module and appropriate software, any LS1010 switch can serve as a means for:
Figure 4-5 shows that an LS1010 switch can make use of a PRS that originates from any one of several sources in the networking environment.
For illustrative purposes, Figure 4-5 shows four possible sources of a PRS. However, you should not interpret Figure 4-5 to mean that only four such clocking signals can be made available for use in the ATM network. In fact, numerous clocking signals may be present in the LS1010 operating environment.
The important concepts that you should take from Figure 4-5 include the following:
Note that each PRS depicted in Figure 4-5 is externally generated—that is, the timing signal originates from a source outside the ATM network proper. Also shown is an OC3 or OC12 trunk line that can propagate a PRS between adjacent ATM networks.
In the event that the priority 1 PRS fails for any reason, the network clock synchronization service automatically recovers network timing by using a priority 2 PRS available from another source.
Assume, for example, that the T1/E1 trunk at the top of Figure 4-5 is currently supplying a priority 1 PRS to the network. Assume further that this PRS fails for some reason. In this event, the OC3/OC12 trunk line (linking the adjacent ATM networks) can provide a secondary (priority 2) PRS for network synchronization purposes.
Similarly, either of the other PBXs connected to the network could each, in turn, provide a PRS to the ATM network in the event of failure of a higher priority PRS.
Note further that, upon restoration to service of the priority 1 PRS, the network clock synchronization service automatically reverts to this PRS for timing purposes, regardless of which lower priority PRS may be active at the time.
Figure 4-6 shows how a PRS for synchronous clocking can be provided to an edge node of an ATM network and propagated through the network to synchronize the flow of CBR data between the communicating ATM end nodes.
In this particular network scenario, a PRS is available to the network by means of the PBX at the edge of the network. Therefore, this PRS is present at the port of a CES module in edge node A (the ingress node). From there, the PRS is propagated into the first ATM network through an ATM port and conveyed across an OC3 trunk to an adjacent ATM network. This same clocking signal is then used to synchronize the handling of CBR data in edge node B (the egress node).
Synchronous Residual Time Stamp (SRTS) clocking can be used if the user's edge equipment is being driven by a different clocking signal than that being used in the ATM network proper. Figure 4-7 shows such an operating scenario in which a timing signal is being provided to edge nodes independently from the ATM network.
Using Figure 4-7 as a frame of reference, assume that the user of edge node 1 wants to send CBR data to a user at edge node 3. In this scenario, SRTS clocking works as follows:
1. Clock A is driving the devices within the ATM network.
2. At edge node 1, the user introduces CBR traffic into the ATM network according to clock B.
3. As edge node 1 segments the CBR bit stream into ATM cells, it measures the difference between user clock B by which it is being driven and network clock A.
4. As edge node 1 generates the ATM cell stream, it incorporates this delta value into every eighth cell.
5. The cells are then propagated through the network in the usual manner.
6. As the cells are received at destination edge node 3, this node not only reassembles the ATM cells into the original CBR bit stream, but also reconciles, or reconstructs, the user clock B timing signal from the delta value carried within every eighth ATM cell.
Thus, during SRTS clocking, CBR traffic is synchronized between the ingress (segmentation) side of the CES circuit and the egress (reassembly) side of the circuit according to user clock signal B, while the ATM network continues to function according to clock A.
Adaptive clocking requires neither the network clock synchronization service nor a global PRS for effective handling of CBR traffic. Rather than using a clocking signal to convey CBR traffic through an ATM network, adaptive clocking infers appropriate timing for data transport by calculating an average data rate for the CBR traffic.
For example, if CBR data is arriving at a CES module at a rate of so many bits per second, then that rate is used, in effect, to govern the flow of CBR data through the network. What happens behind the scenes, however, is that the CES module automatically calculates the average data rate by means of microcode (firmware) built into the board. This calculation occurs dynamically "on the fly" as user data traverses the network.
Thus, when the CES module senses that its segmentation and reassembly (SAR) buffer is filling up, it increases the rate of the transmit (TX) clock for its output port, thereby "draining" the buffer at a rate that is consistent with rate of the data's arrival.
Similarly, the CES module slows down the transmit clock of its output port if it senses that the buffer is being "drained" faster than CBR data is being received. In this manner, adaptive clocking attempts to minimize wide excursions in SAR buffer loading while, at the same time, providing an effective means of propagating CBR traffic through the network.
Relative to the other clocking modes, implementing adaptive clocking is simple and straightforward, since it does not require network clock synchronization services, a PRS, or the advance planning typically associated with developing a logical network timing map. However, adaptive clocking does not support structured CES services, and it exhibits relatively high wander characteristics.
Table 4-2 summarizes the characteristics of the three clocking modes available for handling CBR traffic in an LS1010 networking environment. Although the wander and jitter characteristics of these clocking modes differ, all clocking modes function in a way that preserves the integrity of the user's CBR data, ensuring error-free data transport from source to destination.
Table 4-2 Characteristics of CES Clocking Modes
The following factors enter into proper functioning of CES circuits:
Although synchronous clocking is the recommended (default) clocking mode for CES operations, this fact does not preclude other clocking modes from consideration.
Each end-to-end CES circuit exhibits delay characteristics, based on the following factors:
Each network device contributes some increment of delay, reflecting that device's unique electrical characteristics.
The network designer/administrator calculates a CDV value for each hop in the data path in order to establish a maximum allowable CDV value for the network at large.
A maximum allowable CDV value for the network is calculated by network designers and administrators in order to establish the cell delay tolerance limits for the network. Thus, to some degree, the network's maximum allowable CDV value is a measure of the network's expected performance.
By establishing this CDV threshold for the network, appropriate buffer sizing can be derived for the network devices involved in any given CES circuit, thereby ensuring that the network will operate as expected.
In the case of a CES module, for example, the maximum allowable CDV value for the network is used to determine an appropriate size (depth) for the segmentation and reassembly (SAR) buffer built into the board. This sizing of the SAR buffer is done to prevent buffer overflow or underflow conditions. An overflow condition can cause a loss of frames, while an underflow condition can cause frames to be repeated.
The actual CDV value for a circuit varies according to the particular data path used for the circuit. Consequently, the depth of the SAR buffer may increase or decrease in proportion to the CDV value for the CES circuit being set up.
Note that you can issue the CLI show ces circuit interface command in an unstructured (clear channel) circuit to measure the current CDV value. See the later section "Verifying a Configured Hard PVC (with Adaptive Clocking)" in the chapter "Configuring Port Adapter Modules Interfaces."
For an unstructured hard PVC, the CDV value for the circuit (including all hops) should not exceed a maximum allowable CDV value. The procedure for setting up a hard PVC is described in the section "Configuring CES PAMs for Unstructured CES Services."
For an unstructured soft PVC, the network automatically determines the best data path through the network and handles the routing of CBR traffic. The network accomplishes this dynamically by means of the ATM connection admission control (CAC) mechanism, which determines the best path through the network by executing a routing algorithm that consults local routing tables in network devices.
If the requested data path is equal to or less than the maximum allowable CDV value established by the network administrator, the connection request is granted. If the requested CES circuit exceeds the maximum allowable CDV value, the connection request is denied. These connection admission control processes occur "on the fly" as network connection requests are initiated.
For example, when a user requests a connection from source node A at one edge of the network to destination node B at the opposite edge of the network, the CAC mechanism takes into account the CDV value for each hop in the requested connection to determine a suitable path through the network that does not exceed the network's maximum allowable CDV value.
The procedure for setting up a soft PVC is described in the section "Configuring a Soft PVC (with Synchronous Clocking)" in the chapter "Configuring Port Adapter Modules Interfaces."
The default software image for the LightStream 1010 contains the PNNI routing protocol. The PNNI protocol provides the route dissemination mechanism for complete plug-and-play capability.
The section "Configure ATM Static Routes for IISP or PNNI" describe modifications that may be made to the default PNNI or IISP routing configurations.
For a detailed description of these routing protocols see the section "ATM Routing" in the chapter "LightStream 1010 Product Overview," and see the chapters "Configuring ILMI" and "Configuring ATM Routing and PNNI" for detailed configuration information.
Use the atm route command to configure a static route. Static route configuration allows ATM call setup requests to be forwarded on a specific interface if the addresses match a configured address prefix.
Note An interface must be UNI or IISP to be configured with static route. Static routes configured as PNNI interfaces will default as down.
Figure 4-8 is an example of the atm route command configuring the 13-byte-peer-group-prefix = 47.0091.8100.567.0000.0ca7.ce01 at interface 3/0/0:
Although not required, several system parameters should be set as part of the initial system configuration. To set the system parameters, perform the following tasks in EXEC mode:
| Task | Command |
|---|---|
At the privileged EXEC prompt, enter configuration mode from the terminal. |
|
| 1This command is documented in the LightStream 1010 ATM Switch Command Reference publication. |
hh:mm:ss—Current time in hours (military format), minutes, and seconds.
day —Current day (by date) in the month.
month—Current month (by name).
year—Current year (no abbreviation).
name_string —New case sensitive host name for the network server.
Simple Network Management Protocol (SNMP), an application-layer protocol, facilitates the exchange of management information bases (MIBs) between network devices. SNMP community strings authenticate access to the MIB and function as embedded "passwords."
SNMP may be manually configured using the following defaults:
For definitions of all commands discussed in this chapter, refer to the publication LightStream 1010 ATM Switch Command Reference.
The Simple Network Management Protocol (SNMP) system consists of three parts: an SNMP manager, an SNMP agent, and a Management Information Base (MIB). SNMP is an application-layer protocol that allows SNMP manager and agent stations to communicate. SNMP provides a message format for sending information between an SNMP manager and an SNMP agent. The SNMP manager can be part of a Network Management System (NMS), such as CiscoWorks.
The agent and MIB reside on the switch. In configuring SNMP on the switch, you define the relationship between the manager and the agent.
The SNMP agent contains MIB variables whose values the SNMP manager can request or change. A manager can get a value from an agent or store a value into that agent.The agent gathers data from the MIB, the repository for information about device parameters and network data. The agent can also respond to a manager's requests to get or set data.
An agent can also send unsolicited traps to the manager. Traps are messages alerting the SNMP manager to a condition on the network. Traps can indicate improper user authentication, restarts, link status (up or down), closing of a TCP connection, or loss of connection to a neighbor switch.
Figure 4-9 illustrates the communications relationship between the SNMP manager and agent. It shows that a manager can send the agent requests to get and set MIB values. The agent can respond to these requests. Independent of this interaction, the agent can send unsolicited traps to the manager notifying the manager of network conditions.
Cisco supports the SNMP Version 1 protocol, referred to as SNMPv1, and the SNMP Version 2 protocol, referred to as SNMPv2. Our implementation of SNMP supports all MIB II variables (as described in RFC 1213) and SNMP traps (as described in RFC 1215). Cisco also supports the definition of management information described in RFCs 1155, 1157, and 1213, and supports some or all variables in the MIBs described in the following RFCs: 1156, 1212, 1231, 1243, 1285, 1286, 1315, 1381, 1382, 1398, 1447, 1450, and 1285 (FDDI).
RFC 1447, "SNMPv2 Party MIB" (April 1993), describes the managed objects that correspond to the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies, as defined by the SNMPv2 Administrative Model. RFC 1450, "SNMPv2 MIB," (April 1993) describes the managed objects that instrument the behavior of an SNMPv2 implementation. Cisco supports the MIB variables as required by the conformance clauses specified in these MIBs.
Cisco also provides its own MIB with every system. The Cisco MIB provides a new chassis MIB variable that enables the SNMP manager to gather data on system card descriptions, serial numbers, hardware and software revision levels, and slot locations.
See the Cisco Management Information Base (MIB) User Quick Reference for a detailed description of each Cisco MIB variable and SNMP trap.
Although SNMPv2 offers more robust support than SNMPv1, Cisco continues to support SNMPv1. This is because not all management stations have migrated to SNMPv2 and you must configure the relationship between the agent and the manager to use the version of SNMP supported by the management station.
SNMPv1 offers a community-based form of security defined through an IP address access control list and password. SNMPv2 offers richer security configured through an access policy that defines the relationship between a single manager and agent. SNMPv2 security includes message authentication support using the Message Digest (MD5) algorithm, but because of the Data Encryption Standard (DES) export restrictions, it does not include encryption support through DES. SNMPv2 security provides data origin authentication, ensures data integrity, and protects against message stream modification.
In addition to enhanced security, SNMPv2 support includes a bulk retrieval mechanism and more detailed error message reporting to management stations. The bulk retrieval mechanism supports the retrieval of tables and large quantities of information, minimizing the number of round-trips required.
The SNMPv2 improved error handling support includes expanded error codes that distinguish different kinds of error conditions; these conditions are reported through a single error code in SNMPv1. Error return codes now report the error type. Three kinds of exceptions are also reported: no such object exceptions, no such instance exceptions, and end of MIB view exceptions.
No specific command enables SNMP. The first snmp-server command that you enter enables both versions of SNMP.
To configure SNMP support, perform the tasks in one of the following sections:
To configure relationship between the agent and the manager on the switch, you need to know the version of the SNMP protocol that the management station supports. An agent can communicate with multiple managers; for this reason, you can configure the switch to support communications with one management station using the SNMPv1 protocol and another using the SNMPv2 protocol.
You can perform tasks in the following sections to configure support for both SNMPv1 and SNMPv2 on the switch:
Using SNMP packets, a network management tool can send messages to users on virtual terminals and the console. This facility operates in a similar fashion to the EXEC send command; however, the SNMP request that causes the message to be issued to the users also specifies the action to be taken after the message is delivered. One possible action is a shutdown request. After a system is shut down, typically it is reloaded. Because the ability to cause a reload from the network is a powerful feature, it is protected by the snmp-server system-shutdown global configuration command. If you do not issue this command, the shutdown mechanism is not enabled. To enable the SNMP agent shutdown mechanism, perform the following task:
To understand how to use this feature with SNMP requests, read the document mib.txt available by anonymous FTP from ftp.cisco.com.
You can set the system contact, location, and serial number of the SNMP agent so that these descriptions can be accessed through the configuration file. To do so, perform one or more of the following tasks in global configuration mode:
| Task | Command |
|---|---|
You can set the maximum packet size permitted when the SNMP agent is receiving a request or generating a reply. To do so, perform the following task in global configuration mode:
To monitor SNMP input and output statistics, including the number of illegal community string entries, errors, and requested variables, complete the following task in EXEC mode:
To disable both versions of SNMP (SNMPv1 and SNMPv2) concurrently, perform the following task in global configuration mode:
SNMPv2 security requires that you create an access policy that defines the relationship between a manager and the agent. For each management station with the agent communicates, you must create a separate access policy. Creating an access policy is a multiple-task process:
Step 2 Define a context to identify the object resources that can be acted on.
Step 3 Define a party for both the manager and the agent to identify them.
Step 4 Using the definitions created in the previous tasks, configure the access policy that characterizes the communications that can occur between the manager and the agent. The privileges that you define for the access policy depend on whether the agent is defined as the source or the destination. For example:
Figure 4-10 shows the information exchanged between the manager and the agent. The top arrow, leading from the manager to the agent, shows the types of requests the manager can send to the agent. The bottom arrow, leading from the agent to the manager, shows the kind of information that the agent can send to the manager. Note that the agent sends trap messages to the manager in response to certain network conditions; trap messages are unsolicited and are not related to the request/response communication exchange between the manager and the agent that occurs in relation to MIB variables. For any given manager and agent relationship, the privileges defined in the access policy constrain communications to a specific set of operations.
You must create access policies for each new agent that is installed. You also must create access policies on an agent when new management stations with which the agent will communicate are installed. Moreover, every time a network address changes on a management station, you must reconfigure the access policy to reflect the new information for the management station.
Because the process of creating an access policy is complex and must be performed many times, SNMPv2 offers a single-step method that relies on an accepted set of conventions called the simplified security conventions. You can configure security using this simplified method only if both the agent and the manager support it and consent to use it. The simplified method offers ease of use, but at the cost of forfeiting control over some values that can be configured if you create an access policy.
If you use the simplified security conventions method, the SNMPv2 implementation assumes default values that it determines internally for required information that you cannot provide through the command interface. To use the simplified method, you enter one command supplying a user ID, and optionally, the name of a view, access rights, and a password. The SNMPv2 implementation on the switch derives most of the configuration information from other values.
This section describes each task that you must perform to configure an access policy. Then it addresses the alternative method and describes the task of configuring the user ID for the simplified security conventions method.
To configure support for SNMv2 on the switch, you perform the following tasks:
After you create a record, you can modify the record's contents, changing one or more of the record values. To do this, you issue the command again, naming the record that you created originally. You must fully specify the record values, including the argument values to remain unchanged.
To create or modify an SNMP view record, perform the following task in global configuration mode
| Task | Command |
|---|---|
:
To remove a view record, use the no snmp-server view command.
To create or modify an SNMP context record, perform the following task in global configuration mode:
| Task | Command |
|---|---|
To remove a context entry, use the no snmp-server context command. Specify only the name of the context. The name identifies the context to be deleted.
To create or modify an SNMPv2 party record, perform the following task in global configuration mode
| Task | Command |
|---|---|
snmp-server party party-name party-oid |
:
To remove a party record, use the no snmp-server party command.
To create or modify an SNMPv2 access policy, perform the following task in global configuration mode:
To remove an SNMPv2 access-policy, use the no snmp-server access-policy command. Specify all three arguments to correctly identify the access policy to be deleted. A difference of one value constitutes a unique access policy entry.
To create or modify a simplified security context record, perform the following task in global configuration mode:
To remove a simplified security context record, use the no snmp-server userid command.
Note You may choose to use the same user ID and password across several machines. Because other values are derived internally from the agent's IP address, these configurations are unique.
A trap is an unsolicited message sent by an SNMP agent to an SNMP manager indicating that some event has occurred. The SNMP trap operations allow you to configure the switch to send information to a network management application when a particular event occurs. You can specify the following features for SNMPv2 agent trap operations:
To define the recipient of the trap message, you configure a party record for the manager, including the protocol address, and specify the party record as the destination party for the snmp-server access policy command. To define traps for the agent to send to the manager, perform one or more of the following tasks in global configuration mode:
If the manager supports only the SNMPv1 protocol, you must configure the relationship between the manager and the agent using SNMPv1 support. You can use either of two methods to configure access to the agent. There are trade-offs involved in choosing one method over the other. The methods differ in the following ways:
To configure support for SNMPv1 on the switch, you perform tasks in the following sections:
You can configure a community string, which acts like a password, to permit access to the agent on the switch. Optionally, you can associate a list of IP addresses with that community string to permit only managers with these IP addresses to use the string.
To configure a community string, perform the following task in global configuration mode:
| Task | Command |
|---|---|
You can configure one or more community strings. To remove a specific community string, use the no snmp-server community command.
To create or modify an SNMP view record, perform the following task in global configuration mode
:
To remove a view record, use the no snmp-server view command.
To create or modify an SNMP context record, perform the following task in global configuration mode:
To remove a context entry, use the no snmp-server context command. Specify only the name of the context. The name identifies the context to be deleted.
To create or modify an SNMPv1 party record to be used in an access policy, perform the following task in global configuration mode
| Task | Command |
|---|---|
snmp-server party party-name party-oid |
:
To remove a party record, use the no snmp-server party command.
To configure an access policy, you specify the SNMPv1 proxy for which you configured the party record as both the destination party and the source party. To configure an access policy, perform the following task in global configuration mode:
To remove an SNMP access policy, use the no snmp-server access-policy command. Specify all three arguments to correctly identify the access policy to be deleted. A difference of one value constitutes a unique access policy entry.
The SNMP trap operations allow a system administrator to configure the agent switch to send information to a manager when a particular event occurs. You can specify the following features for SNMP server trap operations:
Perform the following tasks in global configuration mode to define traps for the agent to send to the specified manager:
| Task | Command |
|---|---|
Specify the source interface (and hence IP address) of the trap message. |
|
Define how often to resend trap messages on the retransmission queue. |
|
When autoconfiguration and any manual configurations are complete you should copy the configuration into nonvolatile random-access memory (NVRAM). If you should power off your LightStream 1010 prior to saving the configuration in NVRAM, all manual configuration changes will be lost. Figure 4-11 is an example of the copy running-config command.
When you have finished configuring the LightStream 1010 ATM switch, you can use the following commands to confirm the hardware, software, and interface configuration:
Use the show hardware command to confirm the correct hardware installation. Figure 4-12 provides an example of the show hardware command:
Use the show version command to confirm the correct version and type of LightStream 1010 software is installed and the configuration register. Figure 4-13 is an example of the show version command:
Use the show interface ethernet command to confirm the ethernet interface on the ASP is configured correctly. Figure 4-14 is an example of the show interface ethernet command:
Use the show atm addresses command to confirm correct configuration of the ATM address for the LightStream 1010. Figure 4-15 provides an example of the show atm addresses command:
After you have configured the IP address(es) for the Ethernet interface, test for connectivity between the switch and a host. The host can reside anywhere in your network. To test for Ethernet connectivity, perform the following task:
| Task | Command |
|---|---|
Test the configuration using the ping command. The ping command sends an echo request to the host specified in the command line. |
For example, to test Ethernet connectivity from the switch to a workstation with an IP address of 172.20.40.201, enter the command ping ip 172.20.40.201. If the switch receives a response, the following message is displayed:
Use the ping atm command to confirm that the ATM interfaces are configured correctly. Figure 4-16 is an example of the ping atm command:
Use the show atm interface command to confirm the atm interfaces are configured correctly. Figure 4-17 is an example of the show atm interface command:
Use the show atm status command to confirm the status of ATM interfaces. Figure 4-18 is an example of the show atm status command:
Use the show atm vc command to confirm the status of ATM virtual channels. Figure 4-19 is an example of the show atm vc command:
Use the show running-configuration command to confirm the configuration being used is configured correctly. Figure 4-20 is an example of the write terminal command:
Use the show configuration command to confirm the configuration saved in NVRAM is configured correctly. Figure 4-21 is an example of the show configuration command:
Posted: Thu Jan 23 21:25:12 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
