Академический Документы
Профессиональный Документы
Культура Документы
# chassis-level commands
# fabric link status:
sm-fabric health slot CTX1.sm
# general capabilities and status:
chassis show
# fan and power:
chassis fan-tray show
chassis power show
# restart the entire node. Takes about 10 to 60 minutes, depending on scale of
configuration:
chassis restart
# system-level commands:
system show
system health show
# port commands:
# show ports on a given LM:
port show slot lm2
# show summary port statistics:
port show statistics
# show non-zero summary statistics:
port show statistics active
# show port details:
port show port 2/1
port show port 2/1 statistics
port xcvr show slot lm2
# for a CSLM, show PTP, OTU, and ODU details:
port xcvr show xcvr 4/1 ptp
port otn show otu 4/1
port otn show odu 4/1-1
# capture a system state dump, and FTP it to the given location on an FTP server:
system state-dump ftp-server <ipAddr> login-id anonymous include-corefiles include-
datapath include-optics file-name /state-dump/blddjy02-test
Diagnostics Shell
=================
# invoking the Linux diagnostic shell from the SAOS CLI:
# debug logs are typically saved to the "ramlog" (a circular log buffer)
# to dump the contents of the ramlog:
rld
# to clear the ramlog:
rlc
# to print new logs as they are added to the ramlog:
rld -c
LM Diag Shell
-------------
# very similar to the Linux diagnostics shell on the CTX
# same as CTX, many of the subsystems have debug logs that can be enabled
# For example to enable HAL "xcvr" debug logs:
hal debug set xcvr on
# to view logs as they are printed to the ramlog:
rld -c
# you can run GDB on your workstation and connect to cesd processes on a CTX or LM
for source-level debugging.
# first, run the "setup" utility on the primary CTX diag shell, and enter your FTP
server information.
# You can also choose "blade developers mode" to prevent BladeMgr from resetting
unresponsive blades.
setup
# Then run the "bug" command without argument to connect to cesd-ctm on the primary
CTX,
# or with an LM argument to connect to cesd-pslm on that LM
bug lm2
# it will tell you what command to run on your Linux workstation...
# then on your Linux workstation, from the directory where you built the load that
is running on the node,
# run the bug command, with the IP address of the node:
cd /localdisk/dyurach/perforce/release/saos-8.6.0-pwgw/
./src/software/saos-tce/apps/saos-tce/devscripts/bug thorin lm2 10.184.105.241
# you can now set breakpoints, etc. For example, from GDB:
l halPortDump
b halPortDump
c
# now from the LM diag shell, you can run a command that will cause the breakpoint
to be hit:
hal portDump
# now if you cause a cesd-pslm crash and restart on an LM, you will see the
# blade manager's agent state machine for that blade hit the breakpoint.
# from the LM diag shell:
pkill -SEGV cesd-pslm
# Note that this will cause a core dump to be created. It takes a minute or two:
ls -ltra /var/crash/
# you should probably continue execution quickly after the breakpoint has been hit.
# Otherwise, signal timeouts could cause processes to assert.
# Detaching from the cesd-ctm process doesn't seem to work - cesd-ctm crashes. Be
aware!
del 1
detach
quit
State dumps
===========
# used to capture system state (configuration, log files, core files, etc) for
later debugging
# use the "system state-dump" command on the node to generate a state dump.
# You will usually want to specify the FTP server where the state dump should be
placed.
# The "include-" options specify additional information that should be gathered,
but take longer (10+ minutes):
system state-dump ftp-server 10.177.111.243 login-id anonymous include-corefiles
include-datapath include-optics file-name /state-dump/8700-demo-180410
# "sdpeek" command gathers key information from state dump, useful as a starting
point:
sdpeek -h
sdpeek -a
Primary CTX
-----------
# main state dump file with information gathered from primary CTX:
# date, software load, modules, alarm history, running config, etc
tmp/statedump.txt (or tmp/statedump.txt.gz)
# data gathered from various managers and subsystems on primary CTX:
tmp/*.txt.gz
# default load file:
flash0/config/*
# command logs
flash1/log/cmdLog.*
# event logs
flash1/log/eventLog.*
# fault logs
flash1/fault/*
All Modules
-----------
# various logs are gathered from modules that were accessible at time of state
dump.
# primary CTX is under "./"
# secondary CTX is under "./CTX<n>/"
# each LM is under "./LM<n>/"
# current syslog messages file and most recent archived messages file:
var/log/messages var/log/archive/messages.1.gz
# cesd-ctm logs on CTX:
flash1/log/saosLog.*
# cesd-pslm logs on LM:
flash0/log/saosLog.*
# dmesg preserved after a Linux kernel panic:
var/log/archive/paniclogs/
8700 Simulator
==============
# see https://confluence.ciena.com/display/ces/8700+Simulator and sub-pages
# you can telnet to the primary CTX at the IP address listed in the XML file:
telnet 192.168.122.10
module show
port show
# the diagnostics CLI is available in the console window for each module.
# the "simcli" command can be run to simulate various operations on the module.
# on LM, it can be used to simulate fiber connections between ports:
simcli
set fiber 1 lm VM2 1-A-1 2 save
set fiber 2 lm VM2 1-A-1 1 save
port show
# you can use "stop" and "start" to shut down and start up an existing simulation.
# once you are finished, you can use "destroy" to wipe it out:
src/software/saos-tce/tools/bin/simctrl destroy src/generic/sim/tools/sc/config/my-
simnode-thorin.xml