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:
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:
search cisco.com ## added by cli
domain cisco.com ## added by cli
nameserver x.x.x.x ## added by cli
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.
|
|
|
|
Exits configuration mode.
|
|
|
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
|
|
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
|
|
Exits configuration mode.
|
Step 4
|
copy running-config startup-config
|
(Cisco AXP EXEC mode) Saves the running configuration to the startup configuration.
|
Step 5
|
|
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
2) Americas 5) Asia 8) Europe
3) Antarctica 6) Atlantic Ocean 9) Indian Ocean
2) Antigua & Barbuda 28) Jamaica
3) Argentina 29) Martinique
5) Bahamas 31) Montserrat
6) Barbados 32) Netherlands Antilles
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
19) El Salvador 45) Trinidad & Tobago
20) French Guiana 46) Turks & Caicos Is
21) Greenland 47) United States
23) Guadeloupe 49) Venezuela
24) Guatemala 50) Virgin Islands (UK)
25) Guyana 51) Virgin Islands (US)
Please select one of the following time zone regions.
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
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)
18) Mountain Time - south Idaho & east Oregon
19) Mountain Time - Navajo
20) Mountain Standard Time - Arizona
23) Alaska Time - Alaska panhandle
24) Alaska Time - Alaska panhandle neck
25) Alaska Time - west Alaska
The following information has been given:
Therefore TZ='America/Los_Angeles' will be used.
Is the above information OK?
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.
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
|
|
Enters configuration mode.
|
Step 2
|
|
Reverts to GMT which is the default time zone.
|
Step 3
|
|
Exits configuration mode.
|
Step 4
|
copy running-config startup-config
|
(Cisco AXP EXEC mode) Saves the running configuration to the startup configuration.
|
Step 5
|
|
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
|
|
Enters configuration mode.
|
Step 2
|
clock timezone redefine timezone-name
clock timezone timezone-name 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.
|
|
|
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-2098—Year when daylight savings time begins or ends.
hh:mm—Time when daylight savings time begins or ends.
1-31—Day 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 | last— Specifies 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.
|
|
|
|
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
|
|
Exits configuration mode.
|
Step 4
|
copy running-config startup-config
|
(Cisco AXP EXEC mode) Saves the running configuration to the startup configuration.
|
Step 5
|
|
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
|
|
Enters configuration mode.
|
Step 2
|
clock timezone redefine timezone-name as
tz-definition
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
|
|
Exits configuration mode.
|
Step 4
|
copy running-config startup-config
|
(Cisco AXP EXEC mode) Saves the running configuration to the startup configuration.
|
Step 5
|
|
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
LOCAL MOUNT POINT: /mnt/filesystem/my_mount2
SERVER: 192.168.24.11:/media0
BOUND IN APPLICATION?: 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
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:
|
"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
Device Name Assigned to Alias Product
|
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.
|
Feedback
