> Understanding System Operation and Configuration
> The system provides wireless carriers with a flexible solution that can support a wide variety of services. These services are described in detail in the System Overview Guide.
> Prior to connecting to the command line interface (CLI) and beginning the configuration, there are important things to understand about how the system supports these applications. This chapter provides terminology and background information that must be considered before attempting to configure the system. The following sections are included:
> Terminology
> This section defines some of the terms used in the following chapters.
> Contexts
> A context is a logical grouping or mapping of configuration parameters that pertain to various physical ports, logical IP interfaces, and services. A context can be thought of as a virtual private network (VPN).
> The system supports the configuration of multiple contexts. Each is configured and operates independently from the others. Once a context has been created, administrative users can then configure services, logical IP interfaces, and subscribers for that context. Administrative users then bind the logical interfaces to physical ports.
> Contexts can also be assigned domain aliases; if a subscriber’s domain name matches one of the configured alias names for that context, then that context is used.
> Ports
> Ports are the physical Ethernet connectors (Ethernet 10/100, Ethernet 1000 Line Cards, four-port Quad Gigabit Line Cards (QGLC), and 10-Gigabit Ethernet Line Cards (XGLC) . Ethernet port configuration addresses traffic profiles, data encapsulation methods, media type, and other information for physical connectivity between the system and the rest of the network. Ports are identified by the chassis slot number for the line card, followed by the physical connector number.
> For example, Port 24/1 identifies connector number 1 on the card in slot 24.
> Associate ports with contexts through bindings. For additional information on bindings, refer to the Bindings section below. You can configure each physical port to support multiple logical IP interfaces, each with up to 17 IP addresses (one primary and up to 16 secondaries).
> Logical Interfaces
> You must associate a port with a virtual circuit or tunnel called a logical interface before the port can allow the flow of user data. A logical interface within the system is defined as the logical assignment of a virtual router instance that provides higher-layer protocol transport, such as Layer 3 IP addressing. Interfaces are configured as part of the VPN context and are independent from the physical port that will be used to bridge the virtual interfaces to the network.
> There are several types of logical interfaces to configure to support Simple and Mobile IP data applications.
> Management interface: This interface provides the point of attachment to the management network. The interface supports remote access to the CLI It also supports Common Object Request Broker Architecture (CORBA)-based management via the Web Element Manager application, and event notification via the Simple Network Management Protocol (SNMP).
> Define management interfaces in the local context and bind them to the ports on the Switch Processor Input/Output (SPIO) cards.
> Bindings
> A binding is an association between elements within the system. There are two types of bindings: static and dynamic.

> • | Static binding is accomplished through system configuration. Static bindings associate:

> • | A specific logical interface (configured within a particular context) to a physical port. Once the interface is bound, traffic can flow through the context as if it were any physically-defined circuit. Static bindings support any encapsulation method over any interface and port type.

> • | A service to an IP address assigned to a logical interface within the same context. This allows the interface to take on the characteristics (that is, support the protocols) required by the service.

> • | Dynamic binding associates a subscriber to a specific egress context based on the configuration of their profile or system parameters. This provides a higher degree of deployment flexibility, as it allows a wireless carrier to support multiple services and facilitates seamless connections to multiple networks.

> Services
> Configure services within a context to enable certain functionality. The following are examples of services you can configure on the system, subject to licensing availability and platform type:

> • | GGSN services

> • | SGSN Services

> • | PDSN services

> • | FA services

> • | HA services

> • | LAC services

> • | DHCP services

> • | ASN GW services

> • | ASN Paging Controller and Location Registry services

> • | PDIF services

> • | SCM services (P-CSCF, S-CSCF, A-BG)

> • | Mobility Management Entity (MME) Services

> • | PDN Gateway (P-GW) Services

> • | Serving Gateway (S-GW) Services

> • | Home-NodeB Gateway (HNB-GW) Services

> AAA Servers
> For most configurations, AAA servers are used to store profiles, perform authentication, and maintain accounting records for each mobile data subscriber. The AAA servers communicate with the system over the AAA interface. The system supports the configuration of up to 128 AAA servers.
> It is important to note that for Mobile IP, there can be foreign AAA (FAAA) and home AAA (HAAA) servers. The FAAA server(s) typically resides in the carrier’s network. The HAAA server(s) could be owned and controlled by either the carrier or the home network. If the HAAA server is owned and controlled by the home network, accounting data is transferred to the carrier via a AAA proxy server.
> Important: Mobile IP support depends on the availability and purchase of a standalone HA license or a license bundle that includes HA.
> Subscribers
> Subscribers are the end-users of the service; they gain access to the Internet, their home network, or a public network through the system. There are three primary types of subscribers:

> • | RADIUS-based Subscribers: The most common type of subscriber, these users are identified by their International Mobile Subscriber Identity (IMSI) number, an Electronic Serial Number (ESN), or by their domain name or user name. They are configured on and authenticated by a RADIUS AAA server.

> Upon successful authentication, various attributes that are contained in the subscriber profile are returned. The attributes dictate such things as session parameter settings (for example, protocol settings and IP address assignment method), and what privileges the subscriber has.
> Important: Attribute settings received by the system from a RADIUS AAA server take precedence over local-subscriber attributes and parameters configured on the system.

> • | Local Subscribers: These are subscribers, primarily used for testing purposes, that are configured and authenticated within a specific context. Unlike RADIUS-based subscribers, the local subscriber’s user profile (containing attributes like those used by RADIUS-based subscribers) is configured within the context where they are created.

> When local subscriber profiles are first created, attributes for that subscriber are set to the system’s default settings. The same default settings are applied to all subscriber profiles, including the subscriber named default which is created automatically by the system for each system context. When configuring local profile attributes, the changes are made on a subscriber-by-subscriber basis.
> Important: Attributes configured for local subscribers take precedence over context-level parameters. However, they could be over-ridden by attributes returned from a RADIUS AAA server.

> • | Management Subscribers: A management user is an authorized user who can monitor, control, and configure the system through the command-line interface (CLI) or Web Element Manager application. Management is performed either locally, through the system console port, or remotely through the use of the Telnet or secure shell (SSH) protocols. Management users are typically configured as a local subscriber within the Local context, which is used exclusively for system management and administration. As with a local subscriber, a management subscriber’s user profile is configured within the context where the subscriber was created (in this case, the Local context). However, management subscribers may also be authenticated remotely via RADIUS, if an AAA configuration exists within the local context.

> How the System Selects Contexts
> The previous section of this chapter defined what a context is and how it is used within the system. This section provides details about the process that determines which context to use for context-level administrative user or subscriber sessions. Understanding this process allows you to better plan your configuration in terms of how many contexts and interfaces you need configure.
> Context Selection for Context-level Administrative User Sessions
> The system comes configured with a context called local that you use specifically for management purposes. The context selection process for context-level administrative users (those configured within a context) is simplified because the management port(s) on the SPIO are associated only with the Local context. Therefore, the source and destination contexts for a context-level administrative user responsible for managing the entire system should always be the local context.
> Although this is not commonly done, a context-level administrative user can also connect through other interfaces on the system and still have full system management privileges.
> A context-level administrative user can be created in a non-local context. These management accounts have privileges only in the context in which they are created. This type of management account can connect directly to a port in the context in which they belong, if local connectivity is enabled (SSHD, for example) in that context.
> For all FTP or SFTP connections, you must connect through a SPIO interface. If you SFTP or FTP as a non-local context account, you must use the username syntax of username@contextname.
> The context selection process becomes more involved if you are configuring the system to provide local authentication or work with a AAA server to authenticate the context-level administrative user.
> The system gives you the flexibility to configure context-level administrative users locally (meaning that their profile will be configured and stored in its own memory), or remotely on an AAA server. If a locally-configured user attempts to log onto the system, the system performs the authentication. If you have configured the user profile on an AAA server, the system must determine how to contact the AAA server to perform authentication. It does this by determining the AAA context for the session.
> The following table and figure describe the process that the system uses to select an AAA context for a context-level administrative user.
> Context-level Administrative User AAA Context Selection

> Item | Description
> 1 | During authentication, the system determines whether local authentication is enabled in the local context. If it is, the system attempts to authenticate the administrative user in the local context. If it is not, proceed to item 2 in this table. If the administrative user’s username is configured, authentication is performed by using the AAA configuration within the local context. If not, proceed to item 2 in this table.
> 2 | If local authentication is disabled on the system or if the administrative user’s username is not configured in the local context, the system determines if a domain was received as part of the username. If there is a domain and it matches the name of a configured context or domain, the systems uses the AAA configuration within that context. If there is a domain and it does not match the name of a configured context or domain, Go to item 4 in this table. If there is no domain as part of the username, go to item 3 in this table.
> 3 | If there was no domain specified in the username or the domain is not recognized, the system determines whether an AAA Administrator Default Domain is configured. If the default domain is configured and it matches a configured context, the AAA configuration within the AAA Administrator Default Domain context is used. If the default domain is not configured or does not match a configured context or domain, go to item 4 item this table.
> 4 | If a domain was specified as part of the username but it did not match a configured context, or if a domain was not specified as part of the username, the system determines if the AAA Administrator Last Resort context parameter is configured. If a last resort context is configured and it matches a configured context, the AAA configuration within that context is used. If a last resort context is not configured or does not match a configured context or domain, the AAA configuration within the local context is used.

> ‌
> Context-level Administrative User AAA Context
> Context Selection for Subscriber Sessions
> The context selection process for a subscriber session is more involved than that for the administrative users. Subscriber session context selection information for specific products is located in the Administration Guide for the individual product.
> Understanding the System Boot Process
> Refer to other sections of this guide for information and instructions on configuring the system. Part of the configuration process requires that you allocate hardware resources for processing and redundancy. Therefore, before you configure the system, it is important to understand the boot process which determines how the hardware components are brought on line.
> The following flowchart shows each step in the startup process. For additional information about system configuration files, refer to the Understanding Configuration Files section.
> Boot Process Flowchart
> The following steps describe the system’s boot process:

> Step 1 | When power is first applied to the chassis, or after a reboot, only the SMC slots (slots 8 and 9) receive power. Therefore, the SMCs are the first cards to boot and their LEDs are the first to light up. After the system confirms that cards are located in slots 8 and 9, power is quickly applied to the SPIOs in slots 24 and 25.

> Step 2 | During the startup process, each card performs a series of power-on self tests (POSTs) to ensure that the hardware is operational.

> Step 3 | If the SMC in slot 8 successfully executes all POSTs, the card in slot 8 becomes the active SMC. The SMC in slot 9 becomes the standby card. If there is a problem with the SMC in slot 8, the card in slot 9 becomes the active SMC. Once the active and standby order is determined, the SPIO cards in slots 24 and 25 are placed into active and standby mode, as determined by the direct mapping of the active and standby SMCs.

> Step 4 | The active SMC begins loading the operating system software image designated in the boot stack. The boot stack entries are contained in the boot.sys file that resides on the SMC CompactFlash. The standby SMC observes the active card startup. If the file on the active card is loads normally, the standby SMC boots from the active card image. If the active SMC experiences problems during this phase, the standby card loads its software image designated by its own boot stack entry in its boot.sys file and takes over control of the system as the active card.

> Step 5 | After the software image is loaded into SMC RAM, the active card determines whether other cards are installed in the chassis by applying power to the other chassis slots and signalling them. If the chassis slot contains an application or line card, power is left on to that slot. All empty slots are powered off.

> Important: If no SMCs are installed, or if they are installed incorrectly, no other card installed in the system will boot.

> Step 6 | When power is applied to the PSCs and line cards installed in the system, they each perform their own series of POSTs.

> Step 7 | After successful POST, each of the PSCs enter the standby mode.

> Installed line cards all remain in a ready mode until their corresponding PSC is made active via configuration. After the PSC is made active, the line card installed in the upper-rear chassis slot behind the card is also made active. The line card installed in the lower-rear chassis slot behind the card enters the standby mode.

> Step 8 | After entering the standby mode, each of the PSC control processors (CPs) communicate with the SMC to receive the appropriate code.

> Step 9 | Upon successful loading of the software image, the system loads a configuration file designated in the boot stack (boot.sys file). If this is the first time the system is powered on and there is no configuration file, the active SMC invokes the system’s Quick Setup wizard. Use the Quick Setup wizard to configure basic system parameters for communication across the management network.

> The wizard creates a configuration file, system.cfg, that you can use as a starting point for subsequent configurations. This allows you to configure the system automatically by applying the configuration file during any subsequent boot. For additional information about system configuration files, refer to the Understanding Configuration Files section.
> Understanding Configuration Files
> The system supports the use of a file or script to modify configurable parameters. When you use a file for offline system configuration, it reduces the time it takes to configure parameters on multiple systems.
> A system configuration file is an ASCII text file that contains commands and configuration parameters. When you apply the configuration file, the system parses through the file line by line, testing the syntax and executing the command. If the syntax is incorrect, a message is displayed to the CLI and the system proceeds to the next command. Lines that begin with # are considered remarks and are ignored.
> Important: Pipes ( | ), used with the grep and more keywords, can potentially cause errors in configuration file processing. Therefore, the system automatically ignores keywords with pipes during processing.
> The commands and configuration data within the file are organized and formatted just as they would be if they were being entered at the CLI prompt. For example, if you wanted to create a context called source in the CLI, you would enter the following commands at their respective prompts:
> [local]host_name# config
> [local]host_name(config)# context source
> [source]host_name(config-ctx)# end
> To create a context called source using a configuration file, you would use a text editor to create a new file that consists of the following:
> config
> context source
> end
> There are several important things to consider when using configuration files:

> • | The system automatically applies a configuration file at the end of the boot process. After the system boots up for the first time, a configuration file that you have created and that is tailored to your network needs, can be applied. To make the system use your configuration file, modify the system’s boot parameters according to the instructions located in Software Management Operations.

> • | In addition to being applied during the boot process, you can also apply configuration files manually at any time by executing the appropriate commands at the CLI prompt. Refer to the instructions in Software Management Operations.

> Important: When you apply a configuration file after the boot process, the file does not delete the configuration loaded as part of the boot process. Only those commands that are duplicated are overwritten.

> • | Configuration files can be stored in any of the following locations:

> • | CompactFlash™: Installed on the SPC or SMC

> • | PCMCIA Flash Card: Installed in a slot on the SPC or SMC

> • | Network Server: Any workstation or server on the network that the system can access using the Trivial File Transfer Protocol (TFTP). This is recommended for large network deployments in which multiple systems require the same configuration

> • | Each time you save configuration changes you made during a CLI session, you can save those settings to a file which you can use as a configuration file.

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883