AXP 1.6 User Guide
Configuring the Application Service Environment
Downloads: This chapterpdf (PDF - 328.0KB) The complete bookPDF (PDF - 3.06MB) | Feedback

Configuring the Application Service Environment

Table Of Contents

Configuring the Application Service Environment

Secure Shell Access to the Service Module

Configuring Password Protection

Configuring the SSH Server

Verifying the SSH Server

Virtual Instance Lifecycle Management

Starting the Virtual Instance

Stopping the Virtual Instance

Resetting the Virtual Instance

Reloading the Virtual Instance

Repeated Starting or Stopping the Virtual Instance

Verifying Application Status

Configuring the Hostname

Configuring the Application Domain

DNS Address

Domain Name

Configuring External Network Devices

Attaching a Networking Device to the Application Environment

Detaching a Networking Device from the Application Environment

Configuring IP Static Routes

Configuring NTP

Cisco AXP Clock Time Zone

Configuring the Cisco AXP Clock Time Zone

Example: Configuring Clock Time Zone

Configuring Default Clock Time Zone

Redefining Clock Time Zones

Redefining a Time Zone using Timezone Submode Commands

Redefining a Time Zone with a Single Command

Verifying Clock Configuration

Accessing the Guest Operating System

Displaying Mount Points for an NFS Server

Showing NFS Server Mount Points

Troubleshooting NFS Server Access

Configuring USB Devices

USB Devices

Configuring USB Devices for an Application


Configuring the Application Service Environment


Configuring the application service environment is described in the following sections:

Secure Shell Access to the Service Module

Virtual Instance Lifecycle Management

Configuring the Application Domain

Configuring External Network Devices

Configuring IP Static Routes

Configuring NTP

Cisco AXP Clock Time Zone

Accessing the Guest Operating System

Displaying Mount Points for an NFS Server

Configuring USB Devices

Secure Shell Access to the Service Module

For direct Secure Shell (SSH) access to the Cisco AXP CLI, a user must first session into the service module and configure it.

This initial configuration gives users direct SSH access to the Cisco AXP CLI and also allows them to perform remote configurations without constantly accessing the router and sessioning into the service module.

Cisco AXP provides SSH access to the CLI through a default user that acts like a system administrator. The password for the default system administrator must be configured by the user through the CLI, before SSH access to the Cisco AXP CLI. This password must be at least five characters.

If service password encryption is enabled, the system encrypts the clear text password that is entered and saves it in an encrypted format in the configuration file. A two-character salt string is used by the system.

If the user prefers a clear text password, service password-encryption is disabled by entering the no form of the command.

This section contains the following tasks:

Configuring Password Protection

Configuring the SSH Server

Verifying the SSH Server

Configuring Password Protection

To session into the service module for direct SSH access to the Cisco AXP CLI and to configure the password, perform the following steps:

1. Session into the service module and configure the password.

2. service password-encryption password encrypts the clear text password that is entered and saves it in the encrypted format in the configuration file.

SUMMARY STEPS

1. configure terminal

2. service password-encryption

or

no service password-encryption

3. username sysadmin password clear-password-string

or

username sysadmin password 0 clear-password-string

or

username sysadmin password 7 hashed-password-string

4. exit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure terminal

Enters global configuration mode.

Step 2 

service password-encryption

Encrypts the clear text password using a system provided two-character salt string. The password is saved in the encrypted format in the configuration file.

A clear text password string is encrypted and displayed as a level-7 password string.


no service password-encryption

Keeps the clear text password.

Step 3 

username sysadmin password clear-password-string


Specifies a non-encrypted (cleartext) user password.


username sysadmin password 0 clear-password-string


Specifies a non-encrypted password.


username sysadmin password 7 hashed-password-string

Specifies a hidden password.

Note For Step 3, use one of these three password commands.

Step 4 

exit

Exits configuration mode.

Configuring the SSH Server

To configure SSH access to the CLI server allowing remote access to the Cisco AXP service module, perform the following steps.

SUMMARY STEPS

1. configure terminal

2. ip ssh server

3. ip ssh interface interface

4. exit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure terminal

Enters global configuration mode.

Step 2 

ip ssh server

Enables the SSH service (starts the sshd daemon). Default SSH service is enabled.

If the sshd daemon is running when you configure the no form of the command: the sshd daemon stops, the existing SSH session remains alive, and no new SSH sessions are accepted.

Step 3 

ip ssh interface interface

Specifies the interface on which sshd should listen for an incoming connection.

If you do not use this command, sshd listens on all interfaces.

If sshd is configured to listen to a specific network interface, an IP address change for that interface prevents SSH from accepting a connection on that modified interface.

You must restart sshd or the Cisco AXP service module to re-establish SSH service.

Step 4 

exit

Exits global configuration mode.

Verifying the SSH Server

To verify if the SSH service is running, perform the following steps.

SUMMARY STEPS

1. show processes

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

show processes

Shows the state of the SSHD process.

Virtual Instance Lifecycle Management

The Cisco AXP virtual instance lifecycle manager (VLM) starts, stops, restarts, and monitors the status of all hosted applications. It also provides the status of applications when queried by other services.

Use the [no] shutdown command to start or stop an application service.

Default Startup Sequence

When an application is installed for the first time, the default startup configuration command for the application is no shutdown. The application is online by default.

If the end user changes the running configuration of the application and uses the write memory command to overwrite the startup configuration, then the startup behavior is based on the new configuration. When the system boots up, the application starts according to its startup configuration.

Starting the Virtual Instance

SUMMARY STEPS

1. configure terminal

2. app-service application-name

3. no shutdown

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure terminal

Enters configuration mode.

Step 2 

app-service application-name

Enters application service configuration mode.

Step 3 

no shutdown

Starts the virtual instance. This command is also the default mode.

The virtual instance is online if an error is not returned. If the command fails, check messages.log for an error of the type:

Virtual Instance [name of virtual instance] start failed: [failure reason]

Stopping the Virtual Instance

SUMMARY STEPS

1. configure terminal

2. app-service application-name

3. shutdown

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure terminal

Enters configuration mode.

Step 2 

app-service application-name

Enters application service configuration mode.

Step 3 

shutdown

Stops the virtual instance in the background. If the virtual instance is still running after thirty seconds, it is forced to shut down.

Shutdown errors are logged in the host in /var/log/messages.log.

Resetting the Virtual Instance

SUMMARY STEPS

1. app-service application-name

2. reset

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

app-service application-name

Enters application service mode.

Step 2 

reset

Resets the specified application environment and places it in the current state.

For example:

It forces the virtual environment to stop if it is currently in the shutdown state (offline or pending-offline).

If the virtual environment is currently online, it forces a shutdown and restarts the virtual environment to bring it back online again.

Reloading the Virtual Instance

SUMMARY STEPS

1. reload (Cisco AXP EXEC Mode)

or

reload apps

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

reload

or

reload apps

(Cisco AXP EXEC mode)

reload—reboots the service module. An application shuts down, then the service module reloads. If the shutdown of the application takes longer than the timeout value, the application is forced to shut down. This command always succeeds upon execution—it is not blocked by an application that may be executing another command. Output shutdown errors are logged in the host in /var/log/messages.log.

reload apps—resets all the applications, and reloads the 
virtual instance on the service module without rebooting 
the service module itself. Only resets an application if all 
the applications are not busy. If one or more applications 
are busy, the command returns an error such as 
Virtual Instance <appname> <operation> in progress 

<operation> is one of the following values:

start: application is starting up (either by system or by user)

stop: application is shutting down (either by system or by user)

reset: application is in reset (either by system or by user)

Output errors are logged in the host OS in /var/log/messages.log.

Repeated Starting or Stopping the Virtual Instance

When a command execution does not return an error, it is processed in the order of execution. Consecutive execution of any of the command sequences without return errors processes the lifecycle of the application service in the order of execution.

For example, shutdown followed by a no shutdown command first shuts down the virtual instance to the offline state, followed by starting up the virtual instance and bringing it back to the online state (similar to a reset).

The state of the virtual instance cannot be changed while it is busy processing a previously executed command. If the virtual instance is busy processing a command, and cannot respond to another command, an error of the following type is displayed:

virtual instance <appname> <operation> in progress 

where <operation> is one of:

start: application is starting up (either by system or by user)

stop: application is shutting down (either by system or by user)

reset: application is in reset (either by system or by user)

Verifying Application Status

Use the show state and show app-service state commands to view application status. Refer to "Viewing the Virtual Instance" section on page 122.

Configuring the Hostname

Configure the hostname for the application using the commands shown below.

SUMMARY STEPS

1. configure terminal

2. app-service application-name

3. hostname hostname

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure terminal

Enters global configuration mode.

Step 2 

app-service application-name

Enters application service mode.

Step 3 

hostname hostname

Configures the hostname for the application.

The hostname is limited to 32 characters.

If you enter more than 32 characters, the following error message appears:

Error Message    hostname size greater than 32

Note If hostname is not configured, the default hostname on the host side is used.

This command modifies configuration directives in /etc/hosts and updates the hostname of the hostname-ip mapping entry.

If the file does not exist, the command creates the /etc/hosts file and adds an entry into the file.

If the file exists, (for example, if an application package has already bundled its own /etc/hosts file), the new entries are appended to the existing entries and the original entries remain intact.

The ipaddr in the /etc/hosts file is modified when you use the bind interface command. The first interface binding is used.

The ipaddr is usually eth0 because eth0 is the default and is bound to each virtual instance.

Example:

/etc/hosts:
10.0.0.1 localhost.localdomain  localhost     ## 
added by cli
ipaddr hostname.domain     hostname    ## added by 
cli

Configuring the Application Domain

Using the ip name-server and ip domain-name commands in the host populates the /etc/resolv.conf file in each installed virtual instance. Using these commands to change the configuration in the host results in the /etc/resolv.conf file being updated.

When these commands are used to configure a new name-server and domain-name for a virtual instance (in app-service mode), the /etc/resolv.conf file in that virtual instance is overridden with the new server name and domain name.

The /etc/resolv.conf file in that virtual instance reverts back to the host configuration whenever the virtual instance does not have a name-server or domain-name configured.

Configuring the name-server and domain-server in a virtual instance always takes precedence over configuration in the host.

DNS Address

To configure the address of the domain name server (DNS) for the application, perform the following steps.

SUMMARY STEPS

1. configure terminal

2. app-service application-name

3. ip name-server ip-address

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure terminal

Enters global configuration mode.

Step 2 

app-service application-name

Enters application service mode.

Step 3 

ip name-server ip-address

Configures the IP address (ip-address) of the DNS for the application.

A maximum of two DNSs can be defined.

In a Linux environment, the /etc/resolv.conf file typically contains the IP addresses of name servers (DNS name resolvers) that attempt to translate names into addresses for any node available on the network.

This command creates the /etc/resolv.conf file and adds the name-server entries in it if the file does not exist.

If an application package has already bundled its own /etc/resolv.conf file, the new entries are appended to the existing ones and will leave the original ones intact.

Example:

search localdomain	## added by cli
domain localdomain	## added by cli
nameserver x.x.x.x	## added by cli

Domain Name

To configure the domain name for the application, perform the following steps.

SUMMARY STEPS

1. configure terminal

2. app-service application-name

3. ip domain-name domain name

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure terminal

Enters global configuration mode.

Step 2 

app-service application-name

Enters application service mode.

Step 3 

ip domain-name domain name

Configures the domain name for the application.

The domain name is limited to 64 characters.

If more than 64 characters are entered, the following error message is displayed:

Error Message    domain size greater than 64

Default: The domain name is not configured.

This command modifies configuration directives in /etc/hosts and /etc/resolv.conf files where the domain name is relevant.

This command also modifies the search list for hostname lookup and domain directives for local domain name in /etc/resolv.conf file.

For /etc/hosts file, it updates the domain name of the hostname-ip mapping entry.

Example:

/etc/resolv.conf:
search cisco.com    ## added by cli
domain cisco.com    ## added by cli
nameserver x.x.x.x  ## added by cli

/etc/hosts:
10.100.50.10 appre.cisco.com appre 

Configuring External Network Devices

Each application service environment is configured by default with access to the eth0 network interface, and the loopback interface which automatically binds into the application environment.

Use the bind interface command to bind one or more active network interfaces to the application service environment. A network interface may be shared between application service environments. Up to 64 interfaces are allowed.

Derived network interfaces (such as subinterfaces and VLAN interfaces) must be activated before they are added to the list of available network interfaces. You can configure virtual or VLAN interfaces only if these interfaces are not bound to the virtual hosting environment.

If an interface is bound, an error message which appears contains the specific device name. For example, in the case of the interface eth0.1, the following error message appears: eth0.1 still bound to hosting environment(s), unbind first.

Ensure that your configuration settings do not allow more than one application service environment to compete for the same port on a networking device.

You can configure physical ethernet interfaces on the Cisco AXP service module through the CLI.

Do not remove a built-in physical interface. If you remove a built-in physical interface, an error message such as the following appears: Can not remove the built-in interface eth0/1.

Activation depends on the type of derived network interface. All physical and derived network interfaces have associated configuration commands to adjust IP and firewall settings.


Note The configuration of an IP address cannot be changed for an Router Blade Control Port (RBCP) controlled physical device—these settings are configured on the Cisco ISR.


This section contains the following tasks:

Attaching a Networking Device to the Application Environment

Detaching a Networking Device from the Application Environment

Attaching a Networking Device to the Application Environment

To attach a networking device to/from the application environment, perform the following steps.

SUMMARY STEPS

1. configure terminal

2. interface device-name

3. ip address ip address network-mask

4. exit

5. app-service application-name

6. bind interface network-interface-name

7. end

8. app-service application-name

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure terminal

Enters global configuration mode.

Step 2 

interface device-name

Configures the network interfaces.

device-name—Ethernet device name.

For example, the device name can be eth0 or eth1 for a built-in physical interface, eth0:1 for a virtual interface, or eth0.1 for a VLAN interface.

Step 3 

ip address ip-address network-mask

Configures the IP address and network mask for the specified network interface.

Changing the IP address for a bound interface causes a warning message to appear that shows the application is bound to the interface.

To remove the old IP configuration, reset the virtual instance.

Step 4 

exit

Exits interface configuration mode.

Step 5 

app-service application-name

Enters application service configuration mode.

Step 6 

bind interface network-interface-name

Attaches or detaches a networking device to or from the application environment.

network-interface-name—Interface name defined in the host, for example, the Ethernet device-name defined in the interface command.

The interface is immediately available to the virtual instance with the execution of a new bind command.


Note This command modifies configuration entries in the /etc/hosts file for ipaddr and hostname mapping.


ipaddr in the /etc/hosts file is modified when the command is issued. Only the first interface binding is used. Because eth0 is the default to be bound for each virtual instance, ipaddr is normally eth0.

Step 7 

end

Ends configuration mode.

Step 8 

app-service application-name

Enters application service mode.

Detaching a Networking Device from the Application Environment

To remove a networking device to/from the application environment, perform the following steps.

SUMMARY STEPS

1. configure terminal

2. app-service application-name

3. no bind interface network-interface-name

4. end

5. app-service application-name

6. reset

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure terminal

Enters global configuration mode.

Step 2 

app-service application-name

Enters application service configuration mode.

Step 3 

no bind interface network-interface-name

Detaches a networking device from the application environment.

network-interface-name—Interface name defined in the host, for example, the Ethernet device-name defined in the interface command.

Detaching an interface binding displays the following warning messages:

WARNING!!! Reset the hosting environment

WARNING!!! For binding to be removed

and requires a virtual instance to restart.


Note The networking device is only detached after the final reset command.


Step 4 

end

Ends configuration mode.

Step 5 

app-service application-name

Enters application service mode.

Step 6 

reset

Resets the hosting environment.

Configuring IP Static Routes

Cisco AXP uses statically configured routes to route traffic to a specific interface. The destination network prefix, network prefix mask, and the gateway address are in IPV4 dotted notation (xx.xx.xx.xx).

You can specify multiple route lines in a configuration and use the show ip route command to display the configured routes saved in the database. Some routes are added by default when configuring the interface. The default route for eth0 is configured through the Cisco IOS software CLI.

SUMMARY STEPS

1. configure terminal

2. interface device-name

3. ip route destination-network-prefix network-prefix-mask gateway-address

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure terminal

Enters global configuration mode.

Step 2 

interface device-name

Configures the network interfaces

Step 3 

ip route destination-network-prefix network-prefix-mask gateway-address

Configures the IP route.

destination-network-prefix—IP route prefix for the destination

network-prefix-mask—Prefix mask for the destination

gateway-address—IP address of the gateway.

Configuring NTP

To ensure that the router's time stamps for the logs and development authorization are consistent with those of the Cisco AXP service module, the service module's Network Time Protocol (NTP) clock source must be configured.

The service module can immediately synchronize with the router, provided that the router is set as the master NTP server. You can do this by using the ntp master command.

However, in many cases, the router itself can use a trusted NTP server as its source. Where this is the case, on the service module you can set the same external server as the source for clock synchronization.

Configuring the Cisco AXP service module with an NTP server results in the following:

Clock changes on the NTP server are propagated to the service module. The propagation is gradual, not instantaneous.

Time zone settings and changes on the NTP server are not propagated to the service module.

SUMMARY STEPS


Step 1 On the router:

a. Configure the ISR as an NTP master server.

configure terminal

ntp master

b. (Optional) ntp server {hostname|ip-address}[prefer]

This step is optional but recommended. Use this command to set an external server as the source for providing clock synchronization.

Step 2 On the Cisco AXP service module:

a. Configure the Cisco AXP service module's NTP server to point to the source router providing the clock synchronization.

configure terminal

ntp server router-ip address

end

write memory or copy running-config startup-config


DETAILED STEPS

 
Command or Action
Purpose

Step 1 

Configure the following commands on the router:


configure terminal

Example:

Router# configure terminal

Enters global configuration mode.


ntp master

Configures the router to use its own NTP master clock to synchronize with peers when an external NTP source is unavailable.


(Optional) ntp server {hostname|ip-address}[prefer]

(Optional—recommended.) Sets an external server as the source for clock synchronization.

hostname | ip-address—The hostname or IP address of the external server providing the clock synchronization.

(Optional) prefer—Marks the server as preferred.

Step 2 

Configure the following commands on the Cisco AXP service module:


configure terminal

Example:

SE-Module> config t

Enters configuration mode.


ntp server source-router-ip address

Configures the NTP server to keep the system time in synchronization with the NTP server.

source-router-ip address—IP address of the source server providing the clock synchronization.


end 

Exits configuration mode.


write memory 
or
copy running-config startup-config 

(Cisco AXP EXEC mode) Writes the running configuration to the startup configuration.

Cisco AXP Clock Time Zone

Typically, users of computer systems wish to express time relative to the time zone that is defined for the place where the user is located. During system configuration, the time zone is typically selected by name, or, in some cases, it is selected on a per application or per user basis.

Once the time zone is selected by name, the system should represent time that is consistent with the definition of time in that region. The time should reflect the proper offset from GMT, taking into account the agreed upon rules, if any, for observation of daylight savings time.

The system definition of a time zone can be different from the time zone defined in the region if changes that are made to the public definition of the time zone are not reflected in the system definition of the time zone.

The clock settings and time zone definitions between systems may not always be synchronized. For example, two systems, such as Cisco AXP and Cisco IOS, or Cisco AXP host and guest operating systems (OSs), may share the same clock setting but may display different time stamps because the time zone settings of each system may be different. The same scenario also applies to two different applications such as a Java application and a C application within the same guest operating system.

The converse is also true where two systems or two applications have the same time zone definition but a different clock setting. For example, this occurs if the Cisco AXP service module is not synchronized with the Cisco router.

The clock setting for a guest application is by default synchronized with the Cisco AXP host clock. The host OS clock is affected by the time zone setting of the host OS. To change the time zone of the host environment, refer to the "Configuring the Cisco AXP Clock Time Zone" section. This setting may or may not affect the application.


Note Refer to the product documentation provided by your third-party vendor for application-specific information on clock settings and time zones that may apply to your product.


Configuring the Cisco AXP Clock Time Zone

It is recommended that the Cisco AXP service module be configured with the same time zone as the Cisco IOS router.

The recommended method of time zone configuration in Cisco AXP is by choosing the geographic region where the Cisco AXP system is located.

If the time zone definition is changed on the service module, the new definition becomes effective only after the change is saved to the startup configuration and the service module is reloaded.

A warning message also appears, reminding the user that a different time zone definition is being configured.

SUMMARY STEPS

On the Cisco AXP Service Module:

1. configure terminal

2. clock timezone [timezone-name]

3. end

4. write memory or copy running-config startup-config

5. reload

DETAILED STEPS

 
Command or Action
Purpose

On the Cisco AXP Service Module:

Step 1 

configure terminal 

Enters configuration mode.

Step 2 

clock timezone [timezone-name] 

Sets the time zone on the service module.

timezone-name—The specific name of a place within the region. For example, Eastern Time zone in the USA is identified by the name 'America/New_York.'

If you do not know your time zone name, click Enter and a series of menus will guide you through the time zone selection. The menus are the same as those described for the the clock timezone redefine command. These menus are described in Step 2 onwards in the "Redefining a Time Zone using Timezone Submode Commands" section.

Press ctrl-c at any time to exit this menu.

Step 3 

end 

Exits configuration mode.

Step 4 

write memory 
or
copy running-config startup-config 

(Cisco AXP EXEC mode) Saves the running configuration to the startup configuration.

Step 5 

reload 

Allows the time zone to take effect.

Example: Configuring Clock Time Zone

This example shows the series of interactive menus that guide you through the time zone selection when the clock timezone command is invoked without specifying the time zone name.

se-Module(config)# clock timezone 

Press ctrl-c at any time to exit this menu

Please identify a location so that time zone rules can be set correctly.
Please select a continent or ocean.
1) Africa            4) Arctic Ocean     7) Australia       10) Pacific 
Ocean
2) Americas          5) Asia             8) Europe
3) Antarctica        6) Atlantic Ocean   9) Indian Ocean
#? 2
Please select a country.
  1) Anguilla                 27) Honduras
  2) Antigua & Barbuda        28) Jamaica
  3) Argentina                29) Martinique
  4) Aruba                    30) Mexico
  5) Bahamas                  31) Montserrat
  6) Barbados                 32) Netherlands Antilles
  7) Belize                   33) Nicaragua
  8) Bolivia                  34) Panama
  9) Brazil                   35) Paraguay
10) Canada                   36) Peru
11) Cayman Islands           37) Puerto Rico
12) Chile                    38) St Barthelemy
13) Colombia                 39) St Kitts & Nevis
14) Costa Rica               40) St Lucia
15) Cuba                     41) St Martin (French part)
16) Dominica                 42) St Pierre & Miquelon
17) Dominican Republic       43) St Vincent
18) Ecuador                  44) Suriname
19) El Salvador              45) Trinidad & Tobago
20) French Guiana            46) Turks & Caicos Is
21) Greenland                47) United States
22) Grenada                  48) Uruguay
23) Guadeloupe               49) Venezuela
24) Guatemala                50) Virgin Islands (UK)
25) Guyana                   51) Virgin Islands (US)
26) Haiti
#? 47
Please select one of the following time zone regions.
  1) Eastern Time
  2) Eastern Time - Michigan - most locations
  3) Eastern Time - Kentucky - Louisville area
  4) Eastern Time - Kentucky - Wayne County
  5) Eastern Time - Indiana - most locations
  6) Eastern Time - Indiana - Daviess, Dubois, Knox & Martin Counties
  7) Eastern Time - Indiana - Pulaski County
  8) Eastern Time - Indiana - Crawford County
  9) Eastern Time - Indiana - Pike County
10) Eastern Time - Indiana - Switzerland County
11) Central Time
12) Central Time - Indiana - Perry County
13) Central Time - Indiana - Starke County
14) Central Time - Michigan - Dickinson, Gogebic, Iron & Menominee Counties
15) Central Time - North Dakota - Oliver County
16) Central Time - North Dakota - Morton County (except Mandan area)
17) Mountain Time
18) Mountain Time - south Idaho & east Oregon
19) Mountain Time - Navajo
20) Mountain Standard Time - Arizona
21) Pacific Time
22) Alaska Time
23) Alaska Time - Alaska panhandle
24) Alaska Time - Alaska panhandle neck
25) Alaska Time - west Alaska
26) Aleutian Islands
27) Hawaii
#? 21

The following information has been given:

         United States
         Pacific Time

Therefore TZ='America/Los_Angeles' will be used.
Is the above information OK?
1) Yes
2) No
#? 1

Local time there is now: Tue Jun 23 16:55:01 PDT 2009.
Universal Time is now:   Tue Jun 23 23:55:01 UTC 2009.
Save the change to startup configuration and reload the module for the new timezone to 
take effect.
se-Module(config)#

Configuring Default Clock Time Zone

To revert to the default time zone, which is GMT, use the no clock timezone or default clock timezone or the clock timezone GMT command in Cisco AXP configuration mode.


Note If reverting to the default time zone changes the current time zone on your system, the system warns you to update the startup configuration and restart the system to make the changes take effect.


SUMMARY STEPS

1. configure terminal

2. no clock timezone

or

default clock timezone

or

clock timezone GMT

3. end

4. write memory or copy running-config startup-config

5. reload

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure terminal 

Enters configuration mode.

Step 2 

no clock timezone
or 
default clock timezone 
or 
clock timezone GMT 

Reverts to GMT which is the default time zone.

Step 3 

end 

Exits configuration mode.

Step 4 

write memory 
or
copy running-config startup-config 

(Cisco AXP EXEC mode) Saves the running configuration to the startup configuration.

Step 5 

reload 

Allows the new time zone to take effect.

Redefining Clock Time Zones

When you select a time zone definition on the service module, that definition is what was incorporated into the Cisco AXP 1.5 or higher software installed on the service module.

If your locality changes its definition of a time zone (for example, daylight savings time transition dates), the new definition is not reflected in the Cisco AXP 1.5 software. Hence, it is necessary to redefine the time zone on the service module to match the new time zone definition of your locality.

There are two methods to redefine time zones:

Redefining a Time Zone using Timezone Submode Commands

Redefining a Time Zone with a Single Command


Note If two CLI sessions concurrently enter the timezone submode, each command takes effect in the sequence in which the sessions exit the submode. If you use the same command twice, the last instance of the command supersedes the first one.


Redefining a Time Zone using Timezone Submode Commands

Clock time zones can be redefined by entering clock time zone submode with the
clock timezone redefine command shown in the steps below. The submode commands standard-time and summer-time allow the user to redefine daylight savings time.


Note Avoid changing the timezone label (for example, keep it as EST for Eastern Standard Time)—the changed name of the label may not be universally applied throughout the system.



Note None of the commands to redefine the time zone take effect until you exit the timezone submode. After you exit the timezone submode, the change is only partly effective. After rebooting, the change is fully effective.


SUMMARY STEPS

1. configure terminal

2. clock timezone redefine timezone-name

or

clock timezone timezone-name redefine

or

clock timezone redefine

a. standard-time label -23-23 [0-59]

b. summer-time label date

1-31 start-month 1901-2098 hh:mm

1-31 end-month 1901-2098 hh:mm [0-59]

or

start-month 1-31 1901 - 2098 hh:mm

end-month 1-31 1901 - 2098 hh:mm [0-59]

c. summer-time label recurring

[1-4 | first | last] day-of-week start-month hh:mm
[1-4 | first | last] day-of-week end-month hh:mm [0-59]

d. exit

3. end

4. write memory or copy running-config startup-config

5. reload

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure terminal 

Enters configuration mode.

Step 2 

clock timezone redefine timezone-name 
or
clock timezone timezone-name redefine 
or
clock timezone redefine

Enters time zone submode.

If you do not know your time zone name, click <Enter> and a series of menus will guide you through the time zone selection.


Standard-time label -23-23 [0-59] 

Time zone submode command.

Defines the label used to designate standard time. For example, EST and the offset from GMT in hours and minutes.

If you use this command more than once before exiting the submode, the last instance of it supersedes the earlier one(s).

label—Designates daylight savings time, for example, EST.

-23-23 [0-59]—The offset from GMT in hours and minutes.


summer-time label date 
1-31 start-month 1901-2098 hh:mm 
1-31 end-month 1901-2098 hh:mm [0-59]

or

start-month 1-31 1901 - 2098 hh:mm 
end-month 1-31 1901 - 2098 hh:mm [0-59] 

Defines daylight savings time for a particular range of years for the time zone being defined.

label—Designates daylight savings time, for example, EDT.

start-month—Month when daylight savings time begins.

end-month—Month when daylight savings time ends.

1901-2098Year when daylight savings time begins or ends.

hh:mm—Time when daylight savings time begins or ends.

1-31Day of month when daylight savings time begins or ends.

[0-59]—The adjustment from standard time in hours and minutes when daylight savings time is in effect.


summer-time label recurring 
[1-4 | first | last] day-of-week 
start-month hh:mm [1-4 |  first |  last] 
day-of-week end-month hh:mm [0-59]

Defines daylight savings time for the time zone being defined for all years.

label—Designates daylight savings time, for example, EDT.

1-4 | first | lastSpecifies the location of the day of the week in the month. For example, 2 Monday June means the second Monday in June.

day-of-week—The day of the week.

hh:mm—Time when daylight savings time begins or ends.

[0-59]—The adjustment from standard time in hours and minutes when daylight savings time is in effect.

start-month—Month when daylight savings time begins.

end-month—Month when daylight savings time ends.


exit

Exits time zone submode. If your definition is valid, the timezone you specified is automatically redefined and selected as the system time zone.

If your definition was not valid, the system selects the standard definition.

If your definition results in a change, a message warns you to update the startup-config and restart the system.

Step 3 

end 

Exits configuration mode.

Step 4 

write memory 
or
copy running-config startup-config 

(Cisco AXP EXEC mode) Saves the running configuration to the startup configuration.

Step 5 

reload 

Allows the new time zone to take effect.

Redefining a Time Zone with a Single Command

The command that will be used in this method will succeed only if the timezone-name is a known time zone and if the tz-definition is valid. If the command succeeds, the time zone is revised according to the specified definition and selected as the system time zone.

The command fails if the timezone-name names an unknown time zone or the tz-definition is invalid.

The format of the tz-definition variable is defined in: http://www.gnu.org/software/libtool/manual/libc/TZ-Variable.html.

An extension to the syntax allows an optional year in the DST start and end fields, for example,

EST+5EDT,2007.M3.2.0/2,M11.1.0/2.

The format for the start and end fields is [year.]doy
, where doy = day of year.

SUMMARY STEPS

1. configure terminal

2. clock timezone redefine timezone-name as tz-definition

or

clock timezone timezone-name redefine as tz-definition

3. end

4. write memory or copy running-config startup-config

5. reload

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure terminal 

Enters configuration mode.

Step 2 

clock timezone redefine timezone-name as 
tz-definition 
or
clock timezone timezone-name redefine as 
tz-definition 

Redefines time zone.

If you do not know your time zone name, click <Enter> and a series of menus will guide you through the time zone selection.

Step 3 

end 

Exits configuration mode.

Step 4 

write memory 
or
copy running-config startup-config 

(Cisco AXP EXEC mode) Saves the running configuration to the startup configuration.

Step 5 

reload 

Allows the new time zone to take effect.

Verifying Clock Configuration

Use the show clock detail command to verify the clock settings on the router and the AXP service module.

SUMMARY STEPS

1. On the router:

show clock detail

2. On the AXP service module:

show clock detail

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

On the router:


show clock detail

Example:

Router# show clock detail

00:24:02.669 UTC Sat Oct 27 2007

Time source is NTP

Displays clock settings on the router.

Step 2 

On the Cisco AXP service module:


show clock detail

Example:

se-Module> show clock detail

16:43:30.616 PDT Fri Oct 26 2007

time zone: America/Los_Angeles

clock state: unsync

delta from reference (microsec): 0

estimated error (microsec): 16

time resolution (microsec): 1

clock interrupt period (microsec): 10000

time of day (sec): 1193442210

time of day (microsec): 619436

Displays clock settings on the AXP service module: the timezone currently selected and the redefinition (if the redefinition exists).

Accessing the Guest Operating System


Note Refer to the product documentation provided by your third-party vendor for application-specific access to the guest operating system that may apply to your product.


Use the connect console command to access the guest OS shell. To enable the connect console command, first obtain console access using the postinstall script.

For console access, perform the following steps.

SUMMARY STEPS

1. app-service application-name

2. connect console

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

app-service application-name

Enters application service mode.

Step 2 

connect console

Allows a third-party to integrate their own application commands to the console shell.

On initiating the command, /bin/console executes.

The third-party application must provide its own console file in binary or as a script (telnet to their CLI) to cross connect to their CLI shell.

If the application does not provide a console file, the following message appears:

Error Message    Unable to start console 

Displaying Mount Points for an NFS Server

Access to a Network File System (NFS) server may be provided by the NFS client in an application. For further details, refer to the "NFS Client" section in Cisco AXP Developer Guide.

Displaying the mount points to the NFS server and troubleshooting tips are shown in the following two sections:

Showing NFS Server Mount Points

Troubleshooting NFS Server Access

Showing NFS Server Mount Points

To show the mount points for an NFS server, use the show mounts command:

The show mounts command displays the following values to the screen:

APP NAME—displays the name of the application running in this virtual instance of the guest OS

LOCAL MOUNT POINT—displays the local mount point of the mount from within the guest OS; for example, /mnt/filesystem/my_mount2

SERVER—displays the location (IP address and path) of the NFS server; for example, 192.168.24.11:/media0

BOUND IN APPLICATION—displays True if the application has not unmounted the bind point, False if the application has unmounted the bind point

PINGABLE?—displays True if the server is pingable using the ping command

NFS ACCESSIBLE?—displays True if the server is "NFS accessible"—the server is determined as being accessible if an ls command can be successfully performed on the bind point

Example

In this example, a single subdirectory my_mount2 exists under /mnt/filesystem/.

se-192-168-24-3# show mounts

APP NAME:  iss_test_cat3
    LOCAL MOUNT POINT:  /mnt/filesystem/my_mount2
    SERVER:  192.168.24.11:/media0
	BOUND IN APPLICATION?:  True
    PINGABLE?:  True
	NFS ACCESSIBLE?:  True

Example

In this example, the bind filesystem command has not previously been used to set up a subdirectory to /mnt/filesystem/: therefore, an error message appears.


se-192-168-24-3# show mounts
There are no active mounts
se-192-168-24-3#

Errors for the NFS client are displayed on either the console or in /var/log/messages.log.

Troubleshooting NFS Server Access

The following table shows the troubleshooting tips/actions that may help to diagnose or fix an issue accessing the NFS server mount points.

Error
Troubleshooting Tip/Action

"ERROR: Local mount point <local mount point> must be an empty directory."

The directory within the application space must be empty to avoid mounting over important files.

Do one of the following two steps:

Mount to a different directory that is empty (RECOMMENDED).

Remove the contents of the current directory.

Connect to the application console and enter the following command:

rm -rf <directory>/*

"ERROR: Directory <local mount point> does not exist."

The /mnt/filesystem directory does not have a subdirectory for the application to access.

Connect to the application console and enter the following command:

mkdir -p /mnt/filesystem/localmountdirectoryname

"ERROR: Cannot ping system <server>"

The bind filesystem command first attempts to ping the server at the remote location before mounting the local subdirectory. If the server cannot be reached with a ping, then mounting does not occur.

Check network connectivity by running the following command from the AXP CLI:

ping servername

If the ping command is unsuccessful, check all routing tables between the blade and server to ensure proper network connectivity.

If the ping command is successful, make sure that the application has access to the interface. You may need to bind the application to the interface by using the bind interface command.

"ERROR: App must be `online' or `offline' to bind a filesystem."

The application must be in the online or offline state to allow binding to the remote NFS server location. This error can occur if the application is in the process of coming up or shutting down.

Run the following commands:

show app-service state

This shows if the application is not "online" and is not "offline".

Wait until the application is "online" or "offline"—by periodically reissuing the above command. When the application becomes either online or offline, retry the bind filesystem command.

"ERROR:  AXP could not mount the point 
<local mount point>."

If the mount cannot be created in the AXP host environment, then look in messages.log for further information to help debug the issue. Messages may show improper permissions, or a server sending a "request denied" message to the client.

Perform the following command:
copy tech-support

Perform a clean install of Cisco AXP and try to mount again using the bind filesystem command.

"ERROR: Could not mount the local point <local mount point>."

Occurs if Cisco AXP cannot create a mount point in the application's environment. If this is the case, there should be information in messages.log, both for the application and AXP. To debug this, try the following:

Perform the following commands to help with debugging:

copy tech-support

Examine the messages.log in the host and application.

"ERROR: Could not unmount from the NFS server."

Occurs if the umount utility fails. This can be caused by one of the following reasons:

NFS Server not being reachable.

Ping the server. If this is unsuccessful, do the same action as specified in "ERROR: Cannot ping system <server>" above.

The application is not online or offline.

Run the show app-service state command.

Read the state of the application. Only when the application becomes `online' or `offline' can the umount utility be successful.

The NFS Server is not mounted.

Run the show running-config command.

If the bind filesystem command is not located underneath the application, then the NFS server location is not mounted, and this causes the umount utility to fail.


Configuring USB Devices

After physically attaching USB devices to the USB port on the Cisco AXP service module, you can associate the devices with an application running in a virtual interface.

Check first if the device you want to use is in the categories shown in "USB Devices" section, and then follow the procedure in "Configuring USB Devices for an Application" section to associate the device with an application.

After following the procedure, if the show device usb command does not show your USB device, your device may be unsupported by Cisco AXP.

Cisco AXP uses the kernel modules and files shown in the "Appendix 3: USB Devices" section on page 137.

To support your USB device, you could follow the process for adding additional drivers shown in the document: USB-GPS on AXP 1.5.

USB Devices

Configuring USB Devices for an Application

USB Devices

USB devices from the classes shown in Table 3 can be associated with an application running in a virtual instance. The following types of device cannot be associated with an application: networking, wireless (for example, Bluetooth), and mass storage (portable USB drive with file system).

For a detailed list of tested USB kernel configurations and modules, see the "Appendix 3: USB Devices" section on page 137.

Table 3 USB Device Classes 

Device Category/Class
Examples

Audio

Sound card

Communications

Serial device, modem, and Application Specific Device such as IrDA Bridge, Test and Measurement Class (USBTMC)

Note Devices that expose themselves as "Networking Devices" are not supported.

Human Interface

Keyboard, mouse

Still Image Capture

Still camera

Printer

Printer

Hub

USB Hub (Full speed hub, Hi-speed hub)

Video

Video camera


Configuring USB Devices for an Application

To configure USB devices for an application, perform the following steps:

SUMMARY STEPS

1. Attach the physical devices to a USB port on the service module.

2. show device usb

3. app-service application-name

4. (Optional) bind usb auto

or

5. (Optional) bind usb device name alias

6. show device usb

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

Attach physical devices to USB ports on the service module.

Devices are attached to the router to allow them to be configured.

Step 2 

show device usb


Example:

module# show device usb
Device Name Assigned to    Alias   Product
ttyUSB0     helloworld    --           
ttyUSB1     helloworld    --
ttyUSB2     helloworld    --           
ttyUSB3     helloworld    -- 

A list of devices appears with a name corresponding to each /dev node.

Step 3 

app-service application-name


Example:

app-service HelloWorld

Enters application service configuration mode.

Step 4 

bind usb auto

(Optional) Associates all connected USB devices with the virtual instance for this application. The no form of the command disconnects all USB devices associated with the virtual instance.

Note The bind/association performed by this command has already been done automatically by default after the USB devices were connected to the service module in Step 1.

 

or

 

Step 5 

bind usb device name [alias]


Example:

bind usb device ttyUSB0

bind usb device ttyUSB1 modem


(Optional) Associates a specific USB device with the virtual instance for this application. This allows an alias to be specified.

name: Device name included in the list output by the
show usb devices command.

alias: (Optional) Alternative device name.

Note To disassociate a USB device from this virtual instance, remove the device with the no version of the command. Alternatively, uninstall the application in the virtual instance from the USB device.

Step 6 

show device usb


Example:

module# show device usb

Device Name Assigned to    Alias   Product

ttyUSB0     helloworld    --

ttyUSB1     helloworld    modem

ttyUSB2     helloworld    --

ttyUSB3     helloworld    --           


Displays a list of connected USB devices. For each USB device, the following columns are shown:

Device Name: shows the application of the associated virtual instance.

Assigned to: shows the application to which the physical device is connected .

Alias: alternative name for a device that was optionally specified by the bind usb device name [alias] command.

Product: Product name of the device.

If no USB devices are connected, the message "There are no USB devices connected." appears.