ago 17 2008

Comandos não-documentados do Cisco IOS

Este assunto já saiu em diversos outros sites especializados, como o Nexthop (Brasil) e inúmeros outros, fora. Considero de extrema relevância e pode ser de muito interesse para alguns de vocês! O IOS da Cisco tem uma série de comandos “escondidos”, que não foram documentados em lugar algum. Alguns destes comandos foram incluídos em determinadas versões do sistema para permitir aos desenvolvedores uma flaxibilidade maior nos testes “pré-release”, e acabaram ficando na versão final. Outros foram incluídos pontualmente, para atender à necessidades específicas, e também acabaram sendo incorporados.

Abaixo, uma lista bastante completa destes comandos, com alguns exemplos de utilização.

ATENÇÃO: Alguns destes comandos não têm função alguma (ao menos que se saiba) e alguns podem, inclusive, vir a travar o router caso sejam invocados incorretamente. Portanto, aconselho que não os testem em ambientes de produção.



Fonte: http://www.nthelp.com/cisco_undoc.htm

exec commands

@clear profile (clear cpu profiling)
@debug ip ospf monitor
@debug oir (debug online insertion and removal)
@debug par mo (debug parser modes)
@debug sanity (debug buffer pool sanity)
@debug subsys (debug discrete subsystems)
@debug buffer (additional buffer debugging)
@gdb kernel
@gdb examine pid
@gdb debug pid
@if-console [{slot}] [console|debug]   
@profile {start} {stop} {granularity}.
@sh chunk  (show chunks of memory allocated to processes)
@sh chunk summ (show chunk allocation summary)
@sh idb  (shows interface database)
@sh in stats  (gives you switching path output per interface)
@sh ip ospf maxage-list
@sh ip ospf delete-list
@sh ip ospf statistic
@sh ip ospf bad-checksum
@sh ip ospf event    
@sh isis timers
@sh isis tree  IS-IS link state database AVL tree
@sh isis tree level-2
@sh isis private        
@sh profile [detail|terse] (show cpu profiling)
@sh parser modes (shows current process access-tree.)
@sh parser unresolv (shows unresolved links in access-tree)
@sh list    
@sh list none
@sh region (shows image layout)
@sh region {address} (shows image layout at given address)
@sh timers (show timers for timer command in config mode)
@sh int {INT} switching (shows switching path information for the interface)
@sh proc all-events (shows all process events)
@sh sum (show current stored image checksum)
@test transmit (test the transmission of L2 frames)   

configuration mode commands

@boot system rom
@boot module  
@exception-slave dump X.X.X.X     
@exception-slave protocol tftp
@exception-slave corefile
@ip slow-convergence    
@ip tftp boot-interface         
@loopback diag
@loopback dec (at dec chip)
@loopback test
@loopback micro-linear  
@loopback motorola
@scheduler max-task-time 200 (last val in milliseconds)
@scheduler heapcheck process (memory validation.. after proc)        
@scheduler heapcheck poll (memory valid after some poll)
@scheduler run-degraded   (perhaps in a failure mode?)
@service internal
@service slave-coredump      
@service log backtrace (provides traceback with every logging instance)
@tunnel carry-security

in bgp config:
@neighbor ctalkb-out filter-as 100 d
% filter-as is an obsolete subcommand, use filter-list instead 

in router isis config:


@clear profile

clears out the current CPU profiling configuration.

@debug buffer 

as with buffer sanity checking, no debugging information on lightly
loaded box.

ctalkb#debug buffer
Additional buffer checking debugging is on  

@debug ip ospf monitor

provides information on the status of the ospf process in the debugging

ctalkb#debug ip ospf monitor
OSPF spf monitoring debugging is on   
2w3d: OSPF: Syncing Routing table with OSPF Database
-Traceback= 6064B628 603B6D2C 603B6D18
2w3d: OSPF: Completed Syncing and runtime is 4 msec
-Traceback= 6064B65C 603B6D2C 603B6D18       
2w3d: OSPF: Start redist-scanning
-Traceback= 6064AC20 6062B430 603B6D2C 603B6D18
2w3d: OSPF: Scan for both redistribution and translation
-Traceback= 6064AC60 6062B430 603B6D2C 603B6D18
2w3d: OSPF: End scanning, Elapsed time 0ms
-Traceback= 6064B13C 6062B430 603B6D2C 603B6D18
2w3d: OSPF: Syncing Routing table with OSPF Database
-Traceback= 6064B628 603B6D2C 603B6D18                

ctalkb#debug oir
Online Insertion and Removal debugging is on
2w3d: OIR: Process woke, 'Event', stall=2, usec=0xB6835B36
-Traceback= 6040967C 603B6D2C 603B6D18
2w3d: OIR: Shutdown pulled interface for Serial5/0
-Traceback= 600E30C4 60409204 604096C8 603B6D2C 603B6D18
2w3d: %OIR-6-REMCARD: Card removed from slot 5, interfaces disabled
-Traceback= 60409748 603B6D2C 603B6D18
2w3d: OIR: Remove hwidbs for slot 5
-Traceback= 60409368 60409750 603B6D2C 603B6D18
2w3d: OIR: Process woke, 'Event(max not running)', stall=3,
-Traceback= 6040967C 603B6D2C 603B6D18
2w3d: OIR: Process woke, 'Timer(max running)', stall=3, usec=0xDDBB56D6
-Traceback= 6040967C 603B6D2C 603B6D18
2w3d: OIR: (Re)Init card 5, retry_count=3
-Traceback= 60409894 603B6D2C 603B6D18
2w3d: %OIR-6-INSCARD: Card inserted in slot 5, interfaces administratively
shut down
-Traceback= 604098BC 603B6D2C 603B6D18             

@debug par mo (debug parser modes)

this is used to show what is happening at the parser at specific
instances.  it will show you a basic walkthrough of the lookups needed
to process the cli commands

ctalkb#debug par mo
Parser mode debugging is on       
00:54:40: Look up of parser mode 'controller' succeeded           
00:54:40: Look up of parser mode 'route-map' succeeded

@debug sanity

couldn't get any diagnostic information on this.  router is not
heavily loaded so there isn't much buffer churn and burn to
contend with. 

ctalkb#debug sanity
Buffer pool sanity debugging is on   

@debug subsys

subsystem information indicates a code segment and its version.  when
i had debugging on, i tried reloading the system microcode.  this did
not cause any interesting debugging information. 

ctalkb#debug sub
Subsystem debugging is on        
@debug oir

extended online insertion and removal debugging information. 

@gdb kernel

i couldn't get this to do much besides render the router inoperable. 
there seems to be no interface comparable to the stock gnu debugger.
perhaps there are additional parameters that i am missing.  this applies
to all of the debugger subcommands found.

ctalkb#gdb ker
Kernel GDB allowed on console terminal only

ctalkb#gdb ex 91
||||(lock up)         
@gdb debug pid
ctalkb#gdb debug 91
Can't debug your own process

@if-console [{slot}] [console|debug]   

no output since i don't have a viper router or 12XXX.  however,
this is one of the most interesting hidden commands available for the
cisco.  it allows you to get on a card console (i.e. per individual slot
instead of per individual chassis) and print out extended diagnostic
and debugging information on the specific card.  you enter the card
in unpriv mode and need to enable before seeing all of the commands. 

@profile {start} {stop} {granularity}.

you can setup cpu profiling in the exec mode with the
profile command.  process profiling allows you to find which segment
of code is perhaps hogging the CPU.. what you really need to get use
out of this feature is a symbol table so you can pull the location of
the appropriate segment of code.  the segment is defined by the start
and stop values given to the profile command.  the granularity specifier
allows you to get down to single instruction level. 

the cpu has its own internal timer that is incremented regardless
of whether the desired segment of code is executed.  when the desired
segment of code is executed, a per-profile counter is incremented. 
comparison of this counter with the overall system timer allows you to
get some handle on how much of the cpu the specific segment is using.

ctalkb#profile ?

@show chunk  (show chunks of memory allocated to processes)

there is the traditional malloc/free memory management in place
on the cisco.  there is also chunk allocation.  the main benefit
of chunk allocation over its predecessor is that memory overhead
is only paid by the large chunk (which is then carved up into
smaller pieces) instead of by each individual malloced block.

ctalkb#sh chunk
Chunk Manager:
142 chunks created, 1 chunks destroyed
46 siblings created, 0 siblings trimmed

Chunk element  Block Maximum  Element Element Total
cfgsize Ohead   size element    inuse   freed Ohead    Name
      16     0 65532    3270      717    2553        8 List Elements
      52     0 65532    1168        0    1168        0 List Headers
      16     0 65532    3270        0    3270        8 messages 0x61550068 

@show chunk summ

summary listing of allocated chunks. shows you big chunk size, the
number of siblings divided up within that chunk space as well as
the overhead taken by the chunk. 

ctalkb#sh chunk sum
Chunk Manager:
142 chunks created, 1 chunks destroyed
46 siblings created, 0 siblings trimmed

     Element Sibling size Total   Total   Total   Inuse Ovrhd Chunk
Flag size(b) --range(b)-- Siblg   alloc    Free     HWM   (b) name
D         16   253-  752      0    3270    2553     724     8 ListElements
D         52  1003- 1502      0    1168    1168       0     0 List Headers
D         16   253-  752      0    3270    3270      21     8 messages
D          8   253-  752      0    5450    3974    1476     8 Reg Function

@sh idb 

This command shows the hardware and software interface databases.
this is cisco's way of keeping track of how many interfaces are present
on the system.. includes hardware and software interfaces (physical,
subinterfaces etc).  there is a software limit of 1024 i believe in
ios 11 and 2048 in ios 12.  this is a global limit for the router.


ctalkb#sh idb

19 SW IDBs allocated (2296 bytes each)

9 HW IDBs allocated (4008 bytes each)
HWIDB#1   1   FastEthernet0/0 (Ether)
HWIDB#2   2   Serial2/0:0 (Serial)
HWIDB#3   3   Ethernet3/0 (Ether)
HWIDB#4   4   Ethernet3/1 (Ether)
HWIDB#5   5   Ethernet3/2 (Ether)
HWIDB#6   6   Ethernet3/3 (Ether)
HWIDB#7   7   Serial4/0 (Serial)
HWIDB#8   8   Serial5/0 (Serial)
HWIDB#9   9   Loopback0

@sh in stats  (gives you switching path output per interface)
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor     786433  594121827     556812  177400752
             Route cache     107469    8910774     107451    8925784
                   Total     893902  603032601     664263  186326536      

@sh int e3/0 switching 

goes over some of the basic processes and the data that they are
processing.  shows what switching paths were used for the specific
data counted.  basic processes == IP and routing processes.  others
are lumped into the default category.

ctalkb#sh int e3/0 switching
          Throttle count          0
        Drops         RP          0         SP          0
  SPD Flushes       Fast          0        SSE          0
  SPD Aggress       Fast          0
SPD Priority     Inputs        972      Drops          0

     Protocol       Path    Pkts In   Chars In   Pkts Out  Chars Out
        Other    Process          0          0        167      10020
            Cache misses          0
                    Fast          0          0          0          0
               Auton/SSE          0          0          0          0
           IP    Process       4556     282352       3733     541124
            Cache misses          0                                      

@sh ip ospf maxage-list

don't have ospf running.. would seem that this command shows you
the current value of the max-lsa age.  there is some periodic refresh
which needs to be accounted for.

ctalkb#sh ip ospf max
  AS System N
  Maxage delete timer due in NEVER      

@sh ip ospf delete-list

this command shows you the lsas which have been deleted from
consideration.  as i don't have ospf running, i can't ascertain whether
this is lsas which were taken out of consideration by the SPF algorithm
or by other means.

ctalkb#sh ip ospf delet
  AS System  N

    Area BACKBONE(0)

    ROUTER and NETWORK LSDB delete list

      Dest:, Type: 0, Metric: 1, ADV RTR:
        gateway, interface Loopback0

    SUMMARY NET and ASBR LSDB delete list

    TYPE-7 EXTERNAL LSDB delete list

    EXTERNAL LSDB delete list                     

@sh ip ospf statistic

this is a really handy command because it gives you time averages of
different portions of the ospf process.  this is useful in that it further
lets you pin down IGP convergence times on your network as well as to
isolate the areas which are causing the process to chug.

ctalkb#sh ip ospf stat
  Area 0: SPF algorithm executed 1 times

  SPF calculation time
Delta T   Intra D-Intra Summ    D-Summ  Ext     D-Ext   Total   Reason
2w3d   0        0       0       0       0       0       0       R,

  Avg. and Accumulated time of the last 250 process_ase()

                      Avg.      Accumulated
    ASBR-lookup       0,        0
    Forw-Addr-lookup  0,        0
    compare metric    0,        0             
... (more)

@sh ip ospf bad-checksum

shows LSAs which have failed the checksum.

not sure if this is a count or actual event times since i didn't
have ospf functioning.

@sh ip ospf event    

provides a history lists of subprocess function execution.. useful so that
the operator can understand a bit more about the execution flow

ctalkb#sh ip ospf eve
1    54700   Generic:  ospf_redist_callback  0x618B36A4
2    114716  Generic:  ospf_redist_callback  0x618B36A4
3    174736  Generic:  ospf_redist_callback  0x618B36A4
4    234756  Generic:  ospf_redist_callback  0x618B36A4
5    294772  Generic:  ospf_redist_callback  0x618B36A4
6    320796  Generic:  ospf_build_ex_lsa  0xC658FF00
7    320796  Generic:  ospf_build_ex_lsa  0xAC100000
8    320796  Generic:  ospf_build_ex_lsa  0xD16F5C00  

@sh isis timers

useful in that it provides a brief overview of execution flow
in the isis process.  shows you frequency of things like l1/l2 hello

ctalkb#sh isis timers
  Hello Process
    Expiration    Type
|        0.856  (Parent)
  |        0.856  L2 Hello (Ethernet3/0)
  |        6.352  L1 Hello (Ethernet3/0)
  |        6.940  Adjacency

  Update Process
    Expiration    Type
|        1.060  (Parent)
  |        1.060  Ager
  |        1.352  L2 CSNP (Ethernet3/0)
  |        8.616  L1 CSNP (Ethernet3/0)
  |     3:25.860  (Parent)
    |     3:25.860  LSP refresh
    |     9:02.160  LSP lifetime
    |     9:24.568  LSP lifetime
    |    17:16.084  LSP lifetime
  |    20:58.536  Dynamic Hostname cleanup   

@sh isis tree  IS-IS link state database AVL tree

shows path and depth taken to get to other level 1/2 intermediate
systems in some routing domain.  shows both by default.

ctalkb#sh isis tree

IS-IS Level-2 AVL Tree
Current node = X.X.X.00-00, depth = 0, bal = 0
  Go down left
Current node = X.X.Y.00-00, depth = 1, bal = 0
---} Hit node X.X.Y.00-00
  Back up to X.X.X.00-00
Current node = X.X.X.00-00, depth = 0, bal = 0
---} Hit node X.X.X.00-00
  Go down right
Current node = X.X.X.02-00, depth = 1, bal = 0
---} Hit node X.X.X.02-00
  Back up to X.X.X.00-00             

@sh isis private

displays a little diagnostic information related to the isis process.
ctalkb#sh isis private
ISIS: FastPSNP cache (hits/misses): 0/4002
ISIS: LSPIX validations (full/skipped): 216271/490412
ISIS: LSP HT=0 checksum errors received: 0

@sh list    

perhaps a singly linked list manager which displays global
pointer to the first element in each linked list as well as the
number of members in each list.

ctalkb#     sh list
List Manager:
     1415 lists known, 1561 lists created

   ID   Address  Size/Max   Name
    1  613EE970    11/-     Region List
    2  613EEE98     1/-     Processor
    3  613EFDE8     1/-     I/O
    4  613F0D38     1/-     I/O-2
    5  6149EDD0     0/-     Sched Critical
    6  6149ED90     0/-     Sched High
    7  6149EB00     0/-     Sched Normal  

@sh list none
ctalkb#     sh list none
List Manager:
     1415 lists known, 1561 lists created

   ID   Address  Size/Max   Name
    1  613EE970    11/-     Region List
    2  613EEE98     1/-     Processor
    3  613EFDE8     1/-     I/O
    4  613F0D38     1/-     I/O-2
    9  6149ED10    82/-     Sched Idle
   11  61499A50     8/-     Sched Normal (Old)
   12  6149CC10     1/-     Sched Low (Old)    

@sh parser modes (shows current process access-tree.)
ctalkb#sh par mo
Parser modes:
Name                Prompt              Top       Alias   Privilege
exec                                    0x60EFB294TRUE    TRUE
configure           config              0x60EFABACTRUE    TRUE
interface           config-if           0x60EF7AECTRUE    TRUE
subinterface        config-subif        0x60EF7AECTRUE    FALSE
null-interface      config-if           0x60EFB368TRUE    TRUE
line                config-line         0x60EF3F84TRUE    TRUE        

@sh parser un
ctalkb#sh parser un
Unresolved parse chains:

@sh proc all-events
ctalkb#sh proc all-events
Queue Notifications
     Event    Name                      Pid  1 Process
  61588410    Pool Grows                  4    Pool Manager            ct
  615A156C    Log Messages               19    Logger                  ct
  615EE8A0    IPC inboundQ               11    IPC Seat Manager        ct
  615EE934    IPC Zone inboundQ           9    IPC Zone Manager        ct
  61642840    ARP queue                  12    ARP Input               ct

@sh profile [detail|terse] (show cpu profiling)

ctalkb#sh prof d
Profiling enabled

Block 0: start = 91, end = FFF, increment = 8, EXEC
Total = 0
System total = 9802
ctalkb#sh prof t

@sh region (shows image layout)

displays the program layout for the uncompressed image. 

ctalkb#sh region
Region Manager:

      Start         End     Size(b)  Class  Media  Name
0x07800000  0x07FFFFFF     8388608  Iomem  R/W    iomem2
0x20000000  0x21FFFFFF    33554432  Iomem  R/W    iomem
0x57800000  0x57FFFFFF     8388608  Iomem  R/W    iomem2:(iomem2_cwt)
0x60000000  0x677FFFFF   125829120  Local  R/W    main
0x60008900  0x6123AC29    19079978  IText  R/O    main:text
0x6123C000  0x6136A17F     1237376  IData  R/W    main:data
0x6136A180  0x6152565F     1815776  IBss   R/W    main:bss
0x61525660  0x677FFFFF   103655840  Local  R/W    main:heap  

@sh region {address}

picking a random location within memory shows what segment that
specific address falls under.  same info can be gleaned from the
root command.

ctalkb#sh region a 0x07800000
Address 0x07800000 is located physically in :

  Name  : iomem2
  Class : Iomem
  Media : R/W
  Start : 0x07800000
  End   : 0x07FFFFFF
  Size  : 0x00800000   

@sh  sum

this takes the compressed image and computes its checksum.  this is
compared with the previously stored checksum to ensure integrity.

ctalkb#sh sum
New checksum of 0x36D03E96 matched original checksum

@sh timers (show timers for timer command in config mode)
ctalkb#sh tim

State  Handle  interval     due  invoked   missed   Process 

@test transmit (test the transmission of L2 frames)   

this command allows you to send the specified number of frames
to the specified destination:

ctalkb#test transmit
interface: Ethernet3/0
total frame size [100]:
1) To this interface
2) To another interface
9) Ask for everything
Choice: 2
Encapsulation Type:
1) Ethertype
2) SAP
4) SNAP (Cisco OUI)
5) SNAP (EtherV2 OUI)
6) Novell 802.3
Choice: 1
Protocol type:
1) IP
2) XNS
3) IPX
9) Ask for everything
Choice: 1                


(in config mode)

@boot system rom

if the system has an image burned in on rom, this command allows you to
revert to that image instead of the image stored on some other secondary
media (flash card).

ctalkb(config)#boot system rom
The 'boot system rom' command is not valid for this platform.
It has been translated to 'boot system flash bootflash:' 

@boot module  

the command is there, but it doesn't seem to do anything besides barf.

00:34:02: %PARSER-3-BADSUBCMD: Unrecognized subcommand 11 in configure
command 'boot module a'    

@exception-slave dump X.X.X.X     

informs the router where to dump the core image.

@exception-slave protocol tftp

tells the router what protocol to use when dumping the core image.

@exception-slave corefile

tells the router what to name the corefile.  note that this corefile
has to be at least 666 on the tftp server for the router to be able to
write it.

@ip slow-convergence    

i haven't been able to see any difference in the router performance after
enabling this command.  regardless, it does not look like a command which
would improve the router performance.

@ip tftp boot-interface         

tells the router what interface to find its image in the case that it
wants to boot net via tftp.

@loopback diag

  all of these loopback commands allow you to loop the hardware at
specific points so that you can isolate hardware faults. e.g. this
is not just a loopback net and loopback local command set.  also,
not all pieces of hardware can be looped at all the below points.

@loopback dec (at dec chip)
@loopback test
@loopback micro-linear  
@loopback motorola

@scheduler max-task-time 200 (last val in milliseconds)

this knob allows you to set the number of milliseconds a specific
process is on CPU before it reports debugging information.  a relatively
easy way to report which process is hogging.   sh proc cpu is obviously
the best way to track down cpu hogs while on the router, but this command
allows you to track down more insidious hogs.

00:13:18: %SYS-3-CPUHOG: Task ran for 308 msec (3/1), process = Virtual
Exec, PC = 603C9AD8.

@scheduler heapcheck process (memory validation.. after proc)        
@scheduler heapcheck poll (memory valid after some poll)
@scheduler run-degraded   (perhaps in a failure mode?)

causes the scheduler to attempt to keep running even in the face of some
sort of fatal process error.  the default action of IOS is to have this
knob turned off and to crash the router upon the recognition of a fatal
error.  this is done on a per-process basis.  obviously, some processes
are more critical than others and moving the offending process out of the
scheduler won't really buy you any time or information.

@service internal

this is a really nifty command.  turning it on in global configuration
mode allows you to view some previously hidden commands.  turn it on
by default and you will eventually find some extras. 

some commands are not even accessible unless this is turned on.
(sh proc all-events fex)

@service slave-coredump      

this allows you to dump core when applicable to some slave
machine for logging purposes.  this does take a long time depending
on the amount of memory in the router (copying 128MB with varying
link speeds.  you do the math).  it is important to note that this
copying occurs before the router enters usable mode, so you basically
have added quite a bit of delay into the reload time.   the
exception-slave commands inform the router where to dump the core image.

@service log backtrace (provides traceback with every logging instance)

-Traceback= 603C9AE0 603546C0 60354A48 6035CA58 6035C3F4 6035C34C 60373EBC
603B6D2C 603B6D18
in bgp config:
@neighbor ctalkb-out filter-as 100 d

% filter-as is an obsolete subcommand, use filter-list instead 

this is a nifty command in that it gives you a little more insight
into whats happening.  i would prefer this command even though it
has been deprecated in favor of the filter-list command.  reasoning:
this command is more specific.

in router isis config:

not quite sure what this does since i don't have a complex isis setup to test.

Comente usando o Facebook!

9 comentários

Pular para o formulário de comentário

  1. Marcelo Conterato

    Muito bom Marco, esses comandos “escondidos” são bem interessantes, vou testá-los aqui no simulador. Valew!


  2. Rodrigo C. Soave

    O Marco,vou colocar mais um comentario pra nao ficar tao feio pra voce! elo menos duas respostas!

    E fica aqui mais alguns links de comandos nao documentados.




  3. Marco Filippetti

    POOOO!!!! Tá fraco mesmo!!!! Vou deixar o meu aqui, pra somarem 3 rsrsrsrsrs


  4. Anderson Rodrigues

    hehehehe, se fosse desafio da semana já estariamso no 30º coment. =D

    Alguns destes comandos eu já conhecia, outros são sinistros mew O,O.

    Achei show de bola, Marco/Rodrigo.



  5. Wederson (CeBoLaRk)

    Muito legal o post…




  6. giorgio

    pow estou precisando de informações sobre roteamento cisco !!! livro, tutorial etc… qual quer coisa mande e-mail giorgio08oliveira@hotmail.com


  7. Sergio Abe

    Esses comandos hidden são muito bons.
    Segue mais um, com link do site da CISCO, com relação a um comando que pode ser dado no prompt do roteador :

    Serve para medir e informar o tamanho das Janelas TCP tanto do roteador quanto do micro PC usado na rede LAN.

    segue o link :




    Before You Begin
    Components Used
    Preparing for the TTCP Session
    Performing the Downlink Test (from the Router to the Windows PC)
    Obtaining the Results
    Analyzing the Results
    Performing the Uplink Test (from the Windows PC to the Router)
    General Guidelines
    Related Information


    You can use the Test TCP utility (TTCP) to measure TCP throughput through an IP path. To use it, start the receiver on one side of the path, then start the transmitter on the other side. The transmitting side sends a specified number of TCP packets to the receiving side. At the end of the test, the two sides display the number of bytes transmitted and the time elapsed for the packets to pass from one end to the other. You can then use these figures to calculate the actual throughput on the link. For general information on TTCP, refer to Network Performance Testing with TTCP /images/exit.gif .

    The TTCP utility can be effective in determining the actual bit rate of a particular WAN or modem connection. However, you can also use this feature to test the connection speed between any two devices with IP connectivity between them.
    Before You Begin

    For more information on document conventions, see the Cisco Technical Tips Conventions.

    Readers of this document should be knowledgeable of the following:


    TTCP requires Cisco IOS® Software Version 11.2 or higher and Feature Sets IP Plus (is- images) or Service Provider (p- images).

    Note: The ttcp command is a hidden, unsupported, privileged mode command. As such, its availability may vary from one Cisco IOS software release to another, such that it might not exist in some releases. Some platforms, for instance, require the Cisco IOS Enterprise feature set in order to perform this activity.

    The TTCP software for the client side is available from http://renoir.csc.ncsu.edu/ttcp/; /images/exit.gif download ttcpw.zip /images/exit.gif for Windows clients.

    Components Used

    This document is not restricted to specific software and hardware versions.
    Preparing for the TTCP Session


    Ensure that there is IP connectivity between the two devices involved in the test.

    Download and install the TTCP software for non-IOS clients, if necessary.

    In the example shown below, we try to determine the connection speed of a modem connection between a Microsoft Windows PC and an AS5300 Access Server. Even though many of the topics and explanations that are included here are specific to modem connections, the TTCP utility can be used between any two devices.

    Use the show modem operational-status command (for a modem link) to check the connection parameters. For other LAN or WAN scenarios, this step is not necessary.

    show modem operational-status 1/51 Parameter
    #1 Connect Protocol: LAP-M Parameter #2 Compression:
    None …
    !— Output omitted

    … Parameter #8 Connected Standard:
    V.90 Parameter #9 TX,RX Bit Rate:

    This edited output shows that the client is connected in V.90 at a 45333 bps downlink rate and a 24000 BPS uplink rate. Data compression is disabled on the client modem. Since the TTCP test pattern is highly compressible, any data compression would skew our measure of true modem link throughput.
    Performing the Downlink Test (from the Router to the Windows PC)


    Start the ttcpw program on the PC (in a DOS window), running as a receiver. Refer to the Readme file provided with the windows TTCP software for the appropriate syntax.

    ttcpw -r -s ttcp-r: buflen=8192, nbuf=2048,
    align=16384/0, port=5001 tcp ttcp-r: socket


    Launch the TTCP sender (transmitter) on the AS5300. Leave most settings at the default, except for the number of buffers to transmit. The default number of buffers is 2048, with which the TTCP test would take a long time to complete. By reducing the number of buffers, we are able to finish the test in a reasonable timeframe.

    In the example shown below, we try to determine the connection speed of a modem connection between a Microsoft Windows PC and an AS5300 Access Server. Even though many of the topics and explanations that are included here are specific to modem connections, the TTCP utility can be used between any two devices.

    Note: Try to get a snapshot of the modem (port) operational-status, as described above, just before you begin the TTCP test.

    transmit or receive [receive]:
    !— The AS5300 is the ttcp transmitter

    Target IP address:
    ! — Remote device (the Windows PC) IP address

    perform tcp half close [n]: use tcp driver [n]: send buflen [8192]: send nbuf
    [2048]: 50
    !— Number of buffers to transmit is now set to 50
    (default is 2048 buffers)

    bufalign [16384]: bufoffset [0]: port
    [5001]: sinkmode [y]: buffering on writes [y]: show tcp information at end [n]:
    ttcp-t: buflen=8192, nbuf=50, align=16384/0, port=5001 tcp ->
    ttcp-t: connect (mss 1460, sndwnd 4096, rcvwnd 4128)

    This causes the Cisco IOS TTCP to make a TCP connection to the TTCPW (on the Windows machine).

    When the PC receives the request for the TTCP session, TTCPW displays a message that the PC has accepted a TTCP session from the router’s IP address:

    ttcp-r: accept from

    Obtaining the Results

    When the TTCP sender has finished sending all its data, both sides will print the throughput statistics and terminate. In this case, the IOS TTCP sender shows:

    ttcp-t: buflen=8192, nbuf=50, align=16384/0, port=5001 tcp -> ttcp-t: connect (mss 1460, sndwnd 4096, rcvwnd 4128) ttcp-t: 409600
    bytes in 84544 ms (84.544 real seconds) (~3 kB/s) +++ ttcp-t: 50 I/O calls
    ttcp-t: 0 sleeps (0 ms total) (0 ms average)

    The PC TTCPW receiver, on the other hand, shows:

    409600 bytes in 8
    4.94 seconds = 4.71 KB/sec
    +++ ttcp-r: 79 I/O calls, msec/call = 1101.02, calls/sec =0.93

    At this point, you may want to take another snapshot of the modem or port operational-status. This information can be useful during analysis to check whether, for example, the modem connection experienced any retrains or speedshifts.
    Analyzing the Results

    Since it is most common to evaluate connect speeds in kbps (kilobits per second, or 1000 bits per second) rather that KBps (kilobytes per second, or 1024 bytes per second), we must use the information from TTCP to calculate the bit rate (in kbps). Use the number of bytes received and the transfer time to calculate the actual bit rate for the connection.

    Calculate the bit rate by converting the number of bytes into bits and then divide this by the time for the transfer. In this example, the windows PC received 409600 bytes in 84.94 seconds. We can calculate the bit rate to be (409600 bytes * 8 bits per byte) divided by 84.94 seconds=38577 BPS or 38.577 kbps.

    Note: The receiver-side results are slightly more accurate, since the transmitter might think it is finished after it performs the last write – that is, before the data has actually traversed the link.

    Relative to the nominal link speed of 45333 BPS (determined from the show modem operational-status command), this is an 85 percent efficiency. Such efficiency is normal given the link access procedure for modems (LAPM), PPP, IP and TCP header overhead. If the results are significantly different from what you expect, analyze the operational-status, the modem log and, if necessary, the client-side modem statistics to see what may have happened to impact performance (such as EC retransmits, speedshifts, retrains and so on.)
    Performing the Uplink Test (from the Windows PC to the Router)

    Next, perform an uplink throughput test. This is identical to the downlink test, except that Cisco IOS TTCP acts as the receiver, and Windows TTCPW is the transmitter. First, set up the Router as the receiver, using the default parameters:

    transmit or receive [receive]:
    perform tcp half close [n]: use tcp driver [n]: receive buflen [8192]: bufalign
    [16384]: bufoffset [0]: port [5001]: sinkmode [y]: rcvwndsize [4128]: delayed
    ACK [y]: show tcp information at end [n]: ttcp-r: buflen=8192, align=16384/0,
    port=5001 rcvwndsize=4128, delayedack=yes tcp

    Activate the PC as the TTCP transmitter and specify the IP address of the router. Refer to the Readme file provided with the windows TTCP software for the appropriate syntax:

    TTCPW>ttcpw -t -s -n 50 ttcp-t:
    buflen=8192, nbuf=50, align=16384/0, port=5001 tcp -> ttcp-t:
    socket ttcp-t: connect

    The IOS receiver reports the following results:

    ttcp-r: accept from (mss 1460, sndwnd 4096, rcvwnd
    4128) ttcp-r:
    409600 bytes in 23216 ms (23.216 real seconds)
    (~16kb/s) +++ ttcp-r: 280 I/O calls ttcp-r: 0 sleeps (0 ms total) (0 ms average)

    This comes out as an uplink throughput of 141144 BPS – or almost a 6:1 compression ratio relative to the nominal uplink rate of 24 kbps. This is an interesting result considering hardware compression is disabled (which we determined from show modem operational-status). However, use the IOS command show compress to check whether any software compression is being used.
    General Guidelines

    Here are some general guidelines for using TTCP to measure IP path throughput:


    For meaningful results, the hosts running TTCP should have plenty of CPU power relative to the link speed. This is true when the link is 45 kbps and the hosts are an idle AS5300 and a 700MHz PC. This is not true if the link is 100baseT and one of the hosts is a Cisco 2600 router

    Cisco IOS treats data sourced by the router differently from data routed through the router. In our example above, although Microsoft Point-to-Point Compression (MPPC) compression was negotiated on the link under test, the data transmitted by the router did not use software compression, while the data transmitted by the PC did. This is why the uplink throughput was significantly greater than the downlink throughput. For performance testing of high bandwidth links, you should always test through the routers.

    For IP paths with a large bandwidth * delay product, it is important to use a TCP window size sufficient to keep the pipe full. In the case of modem links, the default 4 KB window size is normally adequate. You can boost the IOS TCP window size with the command i p tcp window-size. Refer to the appropriate documentation for non-IOS systems.

    Another easy way to test the throughput across a modem link is to use the open source tool Through-Putter /images/exit.gif . Install this tool on a web server behind the Access servers and have the Windows PC clients use a browser to call up the Java tool. It can then be used to quickly determine the data rate on a modem connection. This modem throughput applet is open source tool and is not supported by the Cisco Technical Assistance Center. Refer to the Readme file provided with the tool for further installation and operating instructions.


  8. Rodrigo Colen (BH)

    Esse post, eu to querendo copiar inteiro, de tão interessante, as vezes não tenho tempo de ler tudo, mas guardo para ler depois.


    O que acha de implantar aqui o esquema e enviar o post por email? acho que é uma funcionalidade muito util, alem de ajudar a divulgar o blog.

    Rodrigo Colen


  9. Marco Filippetti

    Rodrigo, este sistema já foi implementado faz um tempinho… é o ícone “share this”, que fica logo abaixo do post 😉



Deixe uma resposta