Table Of Contents
Planning for Card and Line Redundancy
Planning Standalone AXSM Configurations with Redundant Lines
Planning Redundant AXSM Configurations with Standalone Lines
Planning Redundant AXSM Configurations with Redundant Lines
Guidelines for Creating an ATM Address Plan
Guidelines for Selecting an Address Format
Address Registration Authorities
Guidelines for Setting the PNNI Level
Selecting the PNNI Peer Group ID
Selecting the ILMI Address Prefix
Selecting the SPVC Address Prefix
Selecting the IISP Address Prefix
Selecting Static Addresses for UNI Ports
Additional Guidelines for Creating an Address Plan
Guidelines for Creating an IP Address Plan
Preparing for Configuration
This chapter introduces common MGX 8850 switch topologies, provides an overview of the configuration process, and presents guidelines for collecting the information you will need to complete the configuration.
Typical Topologies
Release 2.0.12 of the MGX 8850 switch supports the following topologies:
•Core switch
•Multiservice edge aggregation
•DSL edge aggregation
The following sections introduce these topologies.
Core Switch
Figure 1-1 shows the MGX 8850 switch operating in a core switch topology.
Figure 1-1 Core Switch Topology
In the core switch topology, the MGX 8850 switch works with other ATM switches to transfer broadband ATM traffic from one ATM edge device to another. The core acts like a freeway and the edge devices act like freeway on-ramps.
The MGX 8850 switch supports the following types of trunks: DS3, E3, OC-3, OC-12, OC-48, STM-1, STM-4, and STM-16. Typically, core edge nodes communicate with multiple external nodes over relatively slower broadband trunks such as DS3, OC-3, and STM-1trunks. The internal core node communicates with other core nodes using relatively faster links such as OC-12, OC-48, and STM-16 trunks.
Multiservice Edge Aggregation
Figure 1-2 shows the MGX 8850 switch operating in a multiservice edge aggregation topology.
Figure 1-2 Multiservice Edge Aggregation Topology
In the multiservice edge aggregation topology, the MGX 8850 switch is colocated with other ATM equipment and communicates with one or more core switches at remote locations. The MGX 8850 switch aggregates the traffic from multiple local ATM devices, and packages it for high-speed communications over the core.
Typically, multiservice edge nodes communicate with colocated ATM devices over relatively slower broadband trunks such as DS3 and E3 trunks. The multiservice edge node communicates with core nodes using relatively faster links such as OC-12, OC-48, and STM-16 trunks.
The MGX 8850 Release 1 node shown in Figure 1-2 is called a feeder node. For instructions on configuring the MGX 8850 Release 2.0.12 switch to communicate with an MGX 8850 Release 1 feeder node, see "Provisioning AXSM Communication Links."
MGX 8850 edge nodes also support virtual trunks as shown in Figure 1-3.
Figure 1-3 Virtual Trunk Topology
A virtual trunk provides a private virtual network path through an independent network such as a public ATM network. Using virtual trunks, Company A can establish a private virtual path between two sites using a public ATM network that supports this feature. From Company A's point of view, they have a private virtual path between the two sites that can support multiple virtual circuits (VCs). Company A's network topology is completely private, as all communications are simply passed between edge devices, with no need for translation or routing. To accomplish this, the virtual trunk supports the SSCOP (VCI=5), PNNI (VCI=18) and ILMI (VCI=16) signaling protocols.
Figure 1-3 shows two virtual trunks, Virtual Trunk A and Virtual Trunk B. At Private Switch A, both virtual trunks use the same line to connect to the core ATM network. Within the core ATM network, Soft Virtual Permanent Paths (SPVPs) are defined to enable direct communications between the core edge nodes. The result is that Private Switch A has virtual trunks to Private Switches B and C and communicates with them as though they were directly connected to Private Switch A.
DSL Aggregation
Figure 1-4 shows the MGX 8850 switch operating in a Digital Subscriber Link (DSL) edge aggregation topology.
Figure 1-4 DSL Edge Aggregation Topology
In the DSL edge aggregation topology, the MGX 8850 switch is colocated with Digital Subscriber Line Access Multiplexers (DSLAMs) and communicates with one or more core switches at remote locations. The MGX 8850 switch aggregates the DSL traffic from multiple DSLAMs, and packages it for high-speed communications over the core.
Typically, DSL edge nodes communicate with colocated DSLAMs over relatively slower broadband trunks such as DS3 and E3 trunks. The DSL edge node communicates with core nodes using relatively faster links such as OC-3, OC-12, and OC-48 trunks.
Configuration Tasks
Switch configuration is easier if you are familiar with the overall configuration process. To configure and start up the MGX 8850 switch, you need to do some or all of the following:
•Configure general switch features.
•Configure the physical connections to other devices.
•Provision ATM connections to other devices.
•Enable PNNI call routing.
"Configuring General Switch Features," describes how to set up general switch features such as the date, the PNNI controller, and network management. You need to follow the procedures in this chapter to prepare your switch for general operation.
"Preparing AXSM Cards and Lines for Communication," describes how to configure card and line redundancy, and how to bring up lines for physical layer communications.
"Provisioning AXSM Communication Links," describes how to configure ATM communications on the lines and how to configure different types of connections.
For instructions on configuring different ways to manage the MGX 8850 switch, see "Supporting and Using Additional CLI Access Options."
Collecting Information
To successfully configure the MGX 8850 switch, you must collect information about the other devices to which it will connect. You need to know the line speeds and protocols used on the trunks that connect to the switch. You also need to know addressing plan for the network in which the switch is installed. This information can be grouped into the following categories:
•General configuration data
•Edge device and ATM device trunk data
•Core node trunk data
The following sections introduce these types of data and provide guidelines for collecting the data you need for switch configuration.
General Configuration Data
During configuration, you will need to enter general configuration data that describes the switch and how it will be used in the network. This data includes
•Unique switch name
•ATM addressing plan
•IP addressing plan
•Administrator data
•Network clock source plan
•Network management plan
•Line and trunk data
The following sections describe these topics in more detail.
Unique Switch Name
Each switch must have its own unique name (which consists of up to 32 characters) within the ATM network. If you are adding a switch to a network, find out if the network administrator has established switch naming conventions, and find out which names have already been used. It is a good practice to name switches according to location, as this conveys both the switch identity and its location. The procedure for setting the name is described in "Setting and Viewing the Switch Name" in "Configuring General Switch Features."
ATM Addressing Plan
An ATM network addressing plan is critical for successful operation of the MGX 8850 switch in an ATM network. The Private Network-to-Network Interface (PNNI) protocol uses structured network addresses to logically group network devices and determine routes between devices.
PNNI network addressing is described in "Guidelines for Creating an ATM Address Plan," which appears later in this chapter.
IP Addressing Plan
An IP network addressing plan is required for switch management. IP network addressing is described in "Guidelines for Creating an IP Address Plan," which appears later in this chapter.
Administrator Data
In most cases, more than one administrator will manage the switch. The MGX 8850 switch supports multiple administrators and several different administration levels. As part of the planning process, you might want to identify who will be managing the switch and at what level. You can learn more about managing administrators by reading "Configuring User Access" in "Configuring General Switch Features."
Network Clock Source Plan
Clock synchronization in an ATM network is very important. If two switches have trouble synchronizing their communications, traffic between the switches may slow down or stop. Figure 1-5 shows an example network clock source topology.
Figure 1-5 Example Network Clock Source Topology with a Single Master Clock Source
In Figure 1-5, Switch 1 operates as the master network clock source and uses highly accurate external Building Integrated Timing System (BITS) clock sources to time its transmissions to the other switches. These BITS clock sources are T1 or E1 lines with stratum 1, 2, or 3 clock signals. Switch 1 uses one BITS line as the primary clock source and uses the secondary BITS source only if a failure occurs on the primary BITS line. If the primary BITS line fails and recovers, the switch will revert back to the primary line.
Switches 2 through 5 synchronize their transmissions to Switch 1 with the master clock signal, which they receive over AXSM lines. Switch 6 synchronizes its communications using the master clock source, which is forwarded from Switch 3. In this topology, all switches synchronize to the same clock source, and this configuration reduces the possibility that two switches might not be able to synchronize communications.
Figure 1-6 shows an example network clock source topology that uses two master clock sources.
Figure 1-6 Example Network Clock Source Topology with Two Master Clock Sources
In Figure 1-6, Switches 1 and 2 both use BITS clock sources. Switch 1 operates as the master and distributes its BITS clock source over AXSM lines to Switches 2 through 4. Switch 2 is the standby master and receives its primary clock signal over the AXSM line from Switch 1. As long Switch 1 and its primary BITS clock source are operating correctly, the entire network is synchronized to the BITS clock source from Switch 1.
In this example, the secondary clock source for Switch 2 is its BITS clock source, and all other switches are configured to use the AXSM lines from Switch 2 as their secondary clock source. If Switch 1 or its BITS clock source fails, all the switches, including Switch 1, start using the clock signals from Switch 2 for network communications. This configuration preserves network sychronization when either a clock source or a switch fails.
To develop a network clock source plan, create a topology drawing and identify which switches serve as active and standby master clock sources. For each switch that receives clock sources from other switches, indicate which lines carry the primary and secondary clock signals.
When creating your network clock source plan, consider the following:
•Locate the master clock sources near the center of the network to minimize clock signal propagation delay.
•Use the BITS clock interfaces to receive stratum 3 or higher clock signals.
•Use multiple master clock sources to provide fault tolerance.
•If both primary and secondary external clock sources fail, the switch uses an internal stratum 3 clock.
•If the switch is using its own internal stratum 3 clock and a primary or secondary clock source recovers, the switch will use the recovered clock source.
•If no primary or secondary clock sources are configured, the switch uses the internal stratum 3 clock.
•Primary and secondary BITS clocks can be configured after the switch is initialized. For more information, see "Configuring BITS Clock Sources" in "Configuring General Switch Features."
•Primary and secondary AXSM clocks must be configured after the AXSM cards and lines are configured. For more information, see "Configuring AXSM Line Clock Sources" in "Provisioning AXSM Communication Links."
Network Management Plan
You can use the following tools to manage the Cisco MGX 8850 switch:
•Command line interface provided with the switch
•Cisco WAN Manager
•Cisco View
•Third-party SNMP manager
The Command Line Interface (CLI) that comes with the switch is the least expensive option. To use the other tools, you must purchase Cisco WAN Manager (CWM) or a Simple Network Management Protocol (SNMP) manager. The MGX 8850 switch comes with an SNMP agent for use with an SNMP manager.
The advantage to using CWM or an SNMP manager is that you can use one program to simultaneously manage multiple devices. Also, CWM is the only management tool that can configure Service Class Templates (SCTs), which are described in "Provisioning AXSM Communication Links." Most installations require at least one CWM workstation to complete the switch configuration.
Cisco View is a CWM component that can be used independently of CWM to provide limited monitoring and management capabilities.
To determine which versions of CWM and Cisco View are compatible with this MGX 8850 release, refer to the 2.0.12 Version Software Release Notes, Cisco WAN MGX 8850 Software.
For information on managing the switch with an SNMP manager, refer to the following:
•Cisco MGX 8850 AXSM SNMP Reference, Release 2.0
•Cisco MGX 8850 Release 2.0 PXM SNMP Reference
Line and Trunk Data
When configuring lines and trunks that connect the switch to other devices, you need to collect the following types of data:
•Physical line type and configuration
•ATM port configuration
The MGX 8850 switch supports many of the most common ATM configuration parameters. To successfully configure lines and trunks, be sure that the configuration settings used on the switch match the configuration settings used at the other end of the line or trunk. In some cases, options you want to use at one end of the trunk aren't supported at the other end. In these situations, change your configuration plan to use settings that are supported at both ends. "Preparing AXSM Cards and Lines for Communication," describes how to configure physical layer line communications. "Provisioning AXSM Communication Links," describes how to configure ATM ports.
Planning for Card and Line Redundancy
Card redundancy is a feature that associates two cards. If one card fails, the other card assumes operation. PXM45 card redundancy is preconfigured on the MGX 8850 switch. If PXM45 cards and their associated back cards are inserted in slots 7 and 8, they will automatically operate as redundant cards. One card assumes the active role, and the other card operates in standby mode.
AXSM cards and their associated lines can be configured for either standalone or redundant operation. Because a configuration change interrupts service and can require substantial configuration teardown, it is important to develop a redundancy plan early. The redundancy plan determines how AXSM cards must be installed in the chassis, and how lines must connect to the cards. Once the hardware is installed, the software configuration team uses the redundancy plan to configure the switch. The software configuration must match the hardware configuration.
The MGX 8850 switch supports the following card and line redundancy options:
•Standalone AXSM, redundant lines
•Redundant AXSM cards, standalone line
•Redundant AXSM cards, redundant lines
The following sections provide planning guidelines for these configurations.
Planning Standalone AXSM Configurations with Redundant Lines
AXSM cards can operate in either standalone or redundant mode. Standalone mode is the default mode, and standalone cards can be configured for either standalone line operation or Automatic Protection Switching (APS) line operation, which uses redundant lines for fault tolerance. If a standalone AXSM card fails, all calls are lost and the associated lines go out of service. However, if the AXSM card is configured to support redundant lines, a failure on the working line causes a switchover to the protected line, and operation continues.
Figure 1-7 shows how a single AXSM card connects to redundant lines.
Figure 1-7 Standalone AXSM Configuration with Redundant Lines
The redundant lines shown in Figure 1-7 are labeled the working line and the protection line, as defined in the SONET specification for APS. The working line is the primary communications line, and the protection line is the line that will be used if the working line fails.
Two types of APS communications are supported: 1+1 and 1:1. The 1+1 communications type transmits data on both the working line and the protection line. The 1:1 communications type transmits data on either the working line or the protection line.
Notice that both the working line and the protection line connect to the same back card in Figure 1-7. This is why this configuration is also known as an intracard APS configuration. When planning an intracard APS configuration, consider the following:
•The working line and the protection line must connect to adjacent ports on the same back card.
•Because the AXSM-1-2488 has only one OC-48 port on its back card, this card cannot be configured for intracard APS operation (although it can be configured for intercard APS, which is described later in this chapter).
•The switches at both ends of the APS lines must be configured for APS, and the role of each line (working or protection) must be the same at both ends of the line.
Planning Redundant AXSM Configurations with Standalone Lines
In a redundant AXSM configuration, matched sets of front and back cards are installed in the switch, and redundancy is established during software configuration. In a redundant AXSM configuration, a failure on the active AXSM front card causes a switchover to the standby AXSM card set, and no calls are lost.
Note This configuration provides fault tolerance for the AXSM front card only. This configuration does not provide fault tolerance for back cards or lines. If you need this level of protection, use the redundant AXSM configuration with redundant lines.
Figure 1-8 shows how a redundant AXSM cards connect to standalone lines.
Figure 1-8 Redundant AXSM Configuration with Standalone Lines
Figure 1-8 shows two complete sets of AXSM cards. Each port in an active card slot is connected to the corresponding port in the standby card slot through a Y-cable, which joins the two ports to a common line. If the front card in the active card set fails, the standby card set becomes active and continues to support calls over the shared communication line.
When planning a redundant AXSM configuration with a standalone line, consider the following:
•The redundant AXSM cards can be placed anywhere in slots 1 though 6 and slots 9 through 14; they do not have to be installed in adjacent slots, although doing so makes the cabling easier.
•The AXSM card sets must be identical. You cannot pair unmatching cards such as an AXSM T3/E3 card and an AXSM OC-3 card.
•The switch ends of each Y-cable must connect to corresponding ports. For example, the cable connected to line 2 on the active lower bay back card must also connect to line 2 on the standby lower bay back card.
•Optical Y-cables must use SMF cable, not MMF.
•The remote end of the standalone line can connect to a standalone AXSM card or a redundant AXSM card set with a standalone line. (It cannot connect to an AXSM APS port.)
Planning Redundant AXSM Configurations with Redundant Lines
Maximum fault tolerance is achieved when redundant AXSM cards are used with redundant APS lines. In this configuration, fault tolerance is provided for the front card and for the combination of the back card and the communication line. If the working line or the back card to which it is connected fails, communications traffic is rerouted through the protection line and the back card to which it is connected.
Figure 1-9 shows how a redundant AXSM cards connect to redundant APS lines.
Figure 1-9 Redundant AXSM Configuration with Redundant Lines
Figure 1-9 shows two complete sets of AXSM cards. Each port in each card slot connects to an independent line. If the front card in the active card set fails, the standby card set becomes active and continues to support calls over the shared communication line. If the working line fails, communications are rerouted through the protection line for that port.
When planning a redundant AXSM configuration with a redundant lines, consider the following:
•The redundant AXSM cards must be placed in adjacent slots. They can be installed in slots 1 though 6 and slots 9 through 14.
•The AXSM card sets must be identical. You cannot pair unmatching cards such as an AXSM T3/E3 card and an AXSM OC-3 card.
•The redundant back cards must be joined together with the APS mini-backplane.
•The switches at both ends of the APS lines must be configured for APS, and role of each line (working or protection) must be the same at both ends of the line.
Guidelines for Creating an ATM Address Plan
This section lists general guidelines for creating an ATM address plan and explains concepts and issues that apply to PNNI operation on the MGX 8850 switch.
Note All MGX 8850 switches ship with default addresses. These defaults are provided for lab evaluations of the MGX 8850 switch. Before the switch is deployed, Cisco advises you to reconfigure the default addresses using the address plan guidelines in this section.
Planning Overview
At the end of this chapter, there is an Address Plan Worksheet into which you enter your WAN address values. If you are familiar with designing PNNI address structures, or if a plan is already completed, you can go directly to the Address Plan Worksheet and enter the values. Nodal address configuration is explained in "Configuring General Switch Features." Port address configuration is explained in "Provisioning AXSM Communication Links."
The remainder of this chapter explains the following steps that you can use to create a WAN address plan:
1. Selecting an Address Format.
3. Selecting the PNNI Peer Group ID.
6. Selecting the ILMI Address Prefix.
7. Selecting the SPVC Address Prefix.
8. Selecting the IISP Address Prefix.
9. Selecting Static Addresses for UNI Ports.
In a PNNI WAN, the architecture is determined by the node prefixes and addresses. PNNI nodes or peers, broadcast their addresses and prefixes to all other peers in their peer group. Prefixes are partial addresses that are used to summarize a group of addresses. Prefixes reduce overhead in a PNNI network because it is more efficient to advertise one prefix than it is to advertise a group of individual addresses.
Correct address selection will meet the critical WAN architecture goals of
•Performance
•Security
•Network redundancy
•Scalability
Selecting an Address Format
Each PNNI node must be configured for at least one address format. To establish ATM connections, each ATM UNI end system must have at least one ATM end system address (AESA) that uniquely identifies that ATM endpoint. This section explains the supported AESA address formats and their structures.
Caution Each node must support the address format of all its neighboring nodes.
Supported Address Formats
The MGX 8850 supports the following standard ATM formats:
•Native E.164.
•Data Country Code (DCC).
•International Code Designator (ICD).
•AESA-embedded E.164.
•Local AESA.
The native E.164 address specifies an Integrated Services Digital Network (ISDN) number and is used by public PSTNs. A native E.164 address has variable length of up to 15 BCD digits. The other address formats are usually used for private networks. The default address format for the MGX 8850 switch is the ICD format.
In the PNNI network, native E.164 addresses are mapped to an E.164 AESA format. The native AESA will be inserted as a left-justified IDI portion of the AESA, with the semi-octet Hex FFFF padded to form an integral byte at the end. This left-justified rule may be changed to right-justified via CLI if needed.
The substructures of the address formats are transparent to PNNI routing. Figure 1-10 shows the substructures of the supported ATM address formats. Table 1-1 describes the substructures shown in Figure 1-10.
Figure 1-10 Supported ATM Address Formats
Guidelines for Selecting an Address Format
If an address format is already chosen for the WAN, or if your WAN will consist of existing nodes for which an address format has been selected, you can select that address format.
Both Public ATM networks (PSTNs) and Narrowband Integrated Services Digital Networks (N-ISDN) usually use E.164 numbers. This type of deployment is then configured with 11-byte IISP static addressees. PNNI will allow end-system reachability to be advertised via the E.164 address prefix.
In the Data Country Code (DCC) format, each country has a unique DCC code value. If you select this address format, your value must match this standard.
In the International Code Designator (ICD) format, the ICD identifies an organization such as a company or campus. This is a benefit if you are deploying a WAN that will be accessed by several campuses or sites.
Native E.164 addresses can be embedded in the AESA.
Enter the address format or formats that you select into the nodal address worksheet, Table 1-4, which appears at the end of this chapter.
Note Local AFIs should NOT be used for addressing within ATM Service Provider networks.
Address Registration Authorities
Table 1-2 lists the address registration authorities.
Selecting a PNNI Level
The PNNI level defines the position of a switch within the PNNI network. In the current release, the MGX 8850 switch supports one network with a single PNNI level. For evaluation networks, you can accept the default PNNI level, which is 56.
However, if you are deploying the MGX 8850 switch in a production environment, you might want to select a different PNNI level that conforms with a long term PNNI deployment plan. The PNNI standard supports 2 types of topologies: Single Peer Group (SPG) and Multiple Peer Group (MPG). The following sections describe SPG and MPG issues that affect the PNNI level setting.
Single Peer Group Networks
The Cisco MGX 8850 switch currently supports only SPG WANs. Figure 1-11 shows an example topology of a PNNI Single Peer Group WAN.
Figure 1-11 Single Peer Group WAN
In a SPG network, all nodes are in the same group. Although you can configure a PNNI level, or accept the default level, you should not configure more than one level. To define all the nodes as part of the same group, the nodes must all be assigned the same level and group identification number.
Multiple Peer Group Networks
A MPG WAN uses multiple hierarchical levels to logically divide the WAN into levels and peer groups. MPG switches divide the routing database into partitions for each peer group and level. This reduces the amount of network overhead in each peer group, which allows the WAN to support more ATM devices.
Figure 1-12 shows an example topology of a PNNI Multiple Peer Group WAN.
Figure 1-12 Multiple Peer Group (MPG) WAN Topology
As shown in Figure 1-12, lower level numbers indicate peer groups at higher levels in the hierarchy. The level 40 group is highest in the architecture, yet it has a lower number than level 56, which is used by the lowest level peer groups in the example. The level numbers shown are decimal numbers that represent the binary numbers used by the switch.
Guidelines for Setting the PNNI Level
When selecting a level number, you can use any number between 0 and 104, but is generally easier to work with numbers that represent 8-bit boundaries. These numbers are listed in Table 1-3.
As Table 1-3 shows, the PNNI level selects the length of the peer group ID, which is described in the next section. The default PNNI level for the MGX 8850 switch is in the middle of the range of values. Enter the level indicator that you select into the nodal address worksheet, Table 1-4, which appears at the end of this chapter. Remember, in this release, all nodes in the same WAN must be set to the same PNNI level.
Selecting the PNNI Peer Group ID
A node's peer group is determined by its peer group ID, which can be up to 13 bytes long. Figure 1-13 shows the default peer group ID for the MGX 8850 switch.
Figure 1-13 20-byte Default Cisco ATM Address
As Figure 1-13 shows, the peer group ID begins with the left-most or most-significant byte of the ATM address. The PNNI level, which is introduced in the previous section, defines the length of the peer group ID. For example, the Cisco default level indicator is 56, which specifies a peer group ID that is 7 bytes long. Therefore, the default peer group ID for all MGX 8850 nodes is 47 0091 8100 0000.
When planning the peer group ID for your WAN, consider the following:
•All peer group IDs in an SPG must be identical.
•If you change the address format, you need to change the peer group ID.
•If you change any of the identifiers within the area defined by the PNNI level, you must change the peer group ID.
Enter the peer group ID into the nodal address worksheet, Table 1-4, which appears at the end of this chapter.
Selecting the Node Prefix
When a specific ATM address is not defined for the node, the ATM address is defined by the node prefix and the MAC address on the active PXM45 card as shown in Figure 1-13. The node prefix is the first 13-bytes of the node's AESA, and consists of the 7-byte peer group ID (0x47 0091 8100 0000) plus the unique 6-byte MAC address. This is also the default SPVC prefix and ILMI prefix.
The default node prefix also serves as the default PNNI summary address. A summary address is a prefix that PNNI advertises to summarize a group of ATM addresses. One or more summary node prefixes may be configured for each UNI port.
When planning the node prefix for your WAN, remember that the most significant bytes in the node prefix must conform to the peer group ID and PNNI levels.
Enter the node prefix into the nodal address worksheet, Table 1-4, which appears at the end of this chapter.
Selecting the ATM Address
The node ATM address must be unique on the WAN and conform to the selections you have made for the following:
•Address format
•PNNI level
•Peer group ID
To minimize address advertising overhead, the node prefix should match the first 13 bytes of the ATM address.
Figure 1-14 shows the default ATM address for the MGX 8850 switch.
Figure 1-14 20-byte Node Address
The first byte (47) of the default address identifies the address as an International Code Designator (ICD) ATM End Station Address (AESA). The second and third bytes (0091) are the globally unique ICD assigned to Cisco, and the next four bytes (81000000) are identical for all MGX 8850 switches. The unique portion of the default node address is the 6-byte MAC address, which is used in bytes 8 through 13 and again in bytes 14 through 19. Byte 20, which is the selector byte, is set to 00 by default.
You do not have to define ATM addresses for MGX 8850 switches if the combination of the node prefix and the MAC address is acceptable. If you want to create a custom ATM address for the switch, enter the address into the nodal address worksheet, Table 1-4, which appears at the end of this chapter.
Caution The default ATM address is created using the primary PXM45 card's MAC address. If the default address is being used and the primary PXM45 card is replaced, the ATM address of the switch changes. After replacing a PXM45 card, check the switch ATM address and reconfigure it if necessary. To avoid this problem entirely, configure a unique ATM address for the switch.
Selecting the ILMI Address Prefix
The MGX 8850 switch supports ILMI dynamic addressing on UNI ports. When dynamic addressing is enabled, one or more ILMI prefixes can be used to generate ATM addresses for CPE as follows:
1. The CPE retrieves the 13-byte ILMI prefix from the switch.
2. The CPE prepends its 7-bytes with the 13-byte prefix to form its AESA.
3. The ILMI running on the switch registers the constructed AESA on the switch.
The default ILMI prefix matches the node prefix, which minimizes the number of prefixes that need to be advertised.
Because the ILMI prefix is used to address CPE and not PNNI nodes, the ILMI prefix is not dependant on the PNNI level, peer group ID, or node prefix. To avoid ambiguity in the network, ILMI prefixes, which are assigned to specific communication ports, should uniquely identify the devices on those ports.
When ILMI is enabled on a UNI port, you can add up to 16 address prefixes for that port. The same ILMI prefix can be assigned to multiple ports. These ILMI prefixes will be advertised by PNNI to enable SVC routing to this node.
Enter the ILMI prefixes you plan to use into the port address worksheet, Table 1-5, which appears at the end of this chapter.
Selecting the SPVC Address Prefix
If you set up Soft Permanent Virtual Connections (SPVCs), the port at each end of the connection must have a globally unique SPVC address. This address is generated by the switch when the connection is defined and consists of the SPVC prefix and an internally generated number that identifies the port.
The default SPVC prefix matches the default node prefix.
When planning the SPVC prefix for your WAN, consider the following:
•The most significant bytes in the node prefix must conform to the PNNI level and peer group ID.
•The SPVC prefix and the node prefix can be different.
•Once you create a connection using an SPVC prefix, you cannot change the SPVC prefix until all SPVCs have been deleted.
Enter the SPVC prefix into the nodal address worksheet, Table 1-4, which appears at the end of this chapter.
Selecting the IISP Address Prefix
When you configure an IISP link, you must configure one or more static ATM addresses that define devices at the remote end of the link. If you are configuring an IISP link that leads to a single device, you can configure the link with the ATM address of that device. If the IISP link provides communications to multiple devices, you can configure an IISP summary address to represent all the devices. The summary address is a partial ATM address and represents all destinations for which the most-significant bytes of the ATM address match the summary address.
IISP links are typically used to connect to other WANs or LANs, to isolate high-security parts of a WAN, or to reach devices for which ATM addresses should remain unchanged (for example, server farms).
When planning IISP prefixes for your WAN, consider the following:
•Plan for expansion.
•Because the destination devices are not part of the PNNI network, IISP address prefixes do not have to conform to the PNNI level, peer group ID, or node prefix.
•If you are connecting to a network managed by another authority, that authority will probably issue the destination addresses to you.
•You can configure IISP addresses to build static routes within your PNNI WAN.
•The same address can be configured on more than one IISP port, and multiple IISP addresses can be configured on one node.
Enter the IISP prefix into the port address worksheet, Table 1-5, which appears at the end of this chapter.
Selecting Static Addresses for UNI Ports
If ILMI is not enabled for a UNI port, you can add up to 255 static addresses on that port, if this remains within the maximum addresses per node limit. The addresses are not required to be unique within the node, therefore the same address can be assigned to other UNI ports. These addresses are provided to PNNI to be summarized and advertised.
Enter the static addresses into the port address worksheet, Table 1-5, which appears at the end of this chapter.
Additional Guidelines for Creating an Address Plan
The following are guidelines for creating an address plan:
•Select a PNNI level close to the middle of the hierarchy to allow for future expansion.
•Use PNNI levels that fall on 8-byte boundaries. This improves scalability and makes the PNNI level number easier to work with.
•Use default values for as many entities as possible.
•Use IISP links to connect to public WANs.
•Do not use Cisco node address defaults in public WANs, and confirm that each reconfigured node ID and node address is unique. The switch software does not detect configuration errors caused by duplicate ATM addresses.
•Use identical port prefixes where ever possible (ILMI, SPVC, and IISP). Since the port will advertise only one prefix if two or more prefixes match, this reduces advertisements, thereby reducing overhead.
Configuration Worksheets
Table 1-4 is a worksheet that you can use to write down address planning information that applies to the switches in your WAN. Table 1-5 is another worksheet that you can use to write down address planning information that applies to a port on a single switch. To complete an address plan, you would complete one nodal address worksheet for the WAN and an individual port address worksheet for each switch in the WAN.
Table 1-4 Nodal Address Worksheet
Node Name Address Format PNNI Level Peer Group ID Node Prefix and Summary Addresses ATM Address SPVC Prefix
Guidelines for Creating an IP Address Plan
Basic switch configuration and management can be completed using a local terminal. However, to configure and manage the switch from a LAN connection or with CWM, you need an IP connection to the switch, which requires that at least one IP address be configured on the switch.
Note This section discusses remote connectivity through the PXM45 LAN port. You can also use a terminal server to provide LAN connectivity to the PXM45 Console port, which provides greater control than LAN connectivity, but requires an additional piece of equipment. For more information on using terminal servers with the switch, refer to "Setting Up Terminal Server Connections" in "Supporting and Using Additional CLI Access Options."
Typical switch configuration requires either one or two IP addresses for LAN access. When the switch hosts a single PXM45 card, use just one IP address and assign it to both the boot and node IP address options (More on this later in this section.). When the switch uses two PXM45 cards, you can choose to use one or two IP addresses. Figure 1-15 shows a redundant PXM45 configuration that uses two IP addresses.
Figure 1-15 Using Multiple IP Addresses for Switch Access
The configuration shown in Figure 1-15 provides the following benefits:
•Direct access to the active PXM45 using address B.B.B.B.
•Direct access to the standby PXM45 card using address A.A.A.A.
•The boot code on the standby PXM45 card can be upgraded without interrupting service on the active PXM45 card.
•You can perform additional procedures in backup boot mode on the standby card without interrupting the active card. These procedures include hard disk formats and file transfers.
When different IP addresses are use for the boot and node IP addresses, you can manage the active PXM45 card and the switch using the node or disk IP address, which is B.B.B.B in Figure 1-15. You can also access the standby PXM45 card using the boot IP address. When the same address is used for both the boot and node IP addresses, that address can only be used to manage the active PXM45 card.
Note MGX 8850 software releases prior to Release 2.0(12) supported unique addresses for the boot IP addresses on the PXM45 cards in slots 7 and 8. This approach required three unique addresses per switch. Beginning with Release 2.0(12), the boot IP addresses for both slots 7 and 8 must be set to the same IP address.
When planning IP addresses for your switch, use the following guidelines:
•If the switch has one PXM45 card, set the boot and node IP addresses to the same address.
•If the switch has two PXM45 cards and you want to minimize the number of IP addresses used, set both boot IP addresses and the node IP address to the same address.
•If the switch has two PXM45 cards and you want to maximize your control options from remote locations, assign the same boot IP address to each PXM45 card and assign a different IP address to the node IP address.
•Be sure to define the default gateway IP address when defining the boot IP addresses.
•To minimize router configuration, choose boot, node, and default gateway IP addresses that are all on the same subnet.
For instructions on setting boot and node IP addresses, refer to "Setting the Switch IP Addresses" in "Configuring General Switch Features."