Home

Fórum

Moodle

MDs

Cursos ONLINE

FUNCERTI

Políticas / Privacidade

« [CCNA] Desafio da Semana 3 - Agosto de 20087 erros frequentes ao se elaborar um CV »

17 08 2008

Comandos não-documentados do Cisco IOS

Postado por: Marco Filippetti em Curiosidades, Artigos, Cisco - Imprima este post

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ídospontualmente, 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.

Abs!!

Marco.

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)

Share

@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:@partition-avoidance

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

@clear profile

clears out the current CPU profiling configuration.

@debug buffer

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

ctalkb#debug bufferAdditional buffer checking debugging is on

@debug ip ospf monitor

provides information on the status of the ospf process in the debugginglogs.

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

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

@debug par mo (debug parser modes)

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

ctalkb#debug par moParser mode debugging is on00:54:40: Look up of parser mode 'controller' succeeded00: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 tocontend with.

ctalkb#debug sanityBuffer pool sanity debugging is on

@debug subsys

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

ctalkb#debug subSubsystem 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 appliesto all of the debugger subcommands found.

ctalkb#gdb kerKernel GDB allowed on console terminal only

ctalkb#gdb ex 91||||(lock up)

@gdb debug pidctalkb#ctalkb#gdb debug 91Can't debug your own processctalkb#

@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 thecisco. it allows you to get on a card console (i.e. per individual slotinstead of per individual chassis) and print out extended diagnosticand debugging information on the specific card. you enter the cardin 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 theprofile command. process profiling allows you to find which segmentof code is perhaps hogging the CPU.. what you really need to get useout of this feature is a symbol table so you can pull the location ofthe appropriate segment of code. the segment is defined by the startand stop values given to the profile command. the granularity specifierallows you to get down to single instruction level.

the cpu has its own internal timer that is incremented regardlessof whether the desired segment of code is executed. when the desiredsegment 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 ? task start stop hogs {0-FFFFFFFF}

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

there is the traditional malloc/free memory management in placeon the cisco. there is also chunk allocation. the main benefitof chunk allocation over its predecessor is that memory overheadis only paid by the large chunk (which is then carved up intosmaller pieces) instead of by each individual malloced block.

ctalkb#sh chunkChunk Manager:142 chunks created, 1 chunks destroyed46 siblings created, 0 siblings trimmed

Chunk element Block Maximum Element Element Totalcfgsize Ohead size element inuse freed Ohead Name 16 0 65532 3270 717 2553 8 List Elements0x61525688 52 0 65532 1168 0 1168 0 List Headers0x61535684 16 0 65532 3270 0 3270 8 messages 0x61550068

@show chunk summ

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

ctalkb#sh chunk sumChunk Manager:142 chunks created, 1 chunks destroyed46 siblings created, 0 siblings trimmed

Element Sibling size Total Total Total Inuse Ovrhd ChunkFlag size(b) --range(b)-- Siblg alloc Free HWM (b) nameD 16 253- 752 0 3270 2553 724 8 ListElementsD 52 1003- 1502 0 1168 1168 0 0 List HeadersD 16 253- 752 0 3270 3270 21 8 messagesD 8 253- 752 0 5450 3974 1476 8 Reg Function8

@sh idb

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

output:

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)Ethernet3/0 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 areprocessing. shows what switching paths were used for the specificdata counted. basic processes == IP and routing processes. othersare lumped into the default category.

ctalkb#sh int e3/0 switchingEthernet3/0 Throttle count 0 Drops RP 0 SP 0 SPD Flushes Fast 0 SSE 0 SPD Aggress Fast 0SPD 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 youthe current value of the max-lsa age. there is some periodic refreshwhich 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 fromconsideration. as i don't have ospf running, i can't ascertain whetherthis is lsas which were taken out of consideration by the SPF algorithmor by other means.

ctalkb#sh ip ospf delet

AS System N

Area BACKBONE(0)

ROUTER and NETWORK LSDB delete list

Dest: 172.16.0.1, Type: 0, Metric: 1, ADV RTR: 172.16.0.1 Path: gateway 172.16.0.1, 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 ofdifferent portions of the ospf process. this is useful in that it furtherlets you pin down IGP convergence times on your network as well as toisolate the areas which are causing the process to chug.

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

SPF calculation timeDelta T Intra D-Intra Summ D-Summ Ext D-Ext Total Reason2w3d 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'thave ospf functioning.

@sh ip ospf event

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

ctalkb#sh ip ospf eve1 54700 Generic: ospf_redist_callback 0x618B36A42 114716 Generic: ospf_redist_callback 0x618B36A43 174736 Generic: ospf_redist_callback 0x618B36A44 234756 Generic: ospf_redist_callback 0x618B36A45 294772 Generic: ospf_redist_callback 0x618B36A46 320796 Generic: ospf_build_ex_lsa 0xC658FF007 320796 Generic: ospf_build_ex_lsa 0xAC1000008 320796 Generic: ospf_build_ex_lsa 0xD16F5C00

@sh isis timers

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

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 intermediatesystems in some routing domain. shows both by default.

ctalkb#sh isis tree

IS-IS Level-2 AVL TreeCurrent node = X.X.X.00-00, depth = 0, bal = 0 Go down leftCurrent node = X.X.Y.00-00, depth = 1, bal = 0---} Hit node X.X.Y.00-00 Back up to X.X.X.00-00Current node = X.X.X.00-00, depth = 0, bal = 0---} Hit node X.X.X.00-00 Go down rightCurrent 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 privateISIS: FastPSNP cache (hits/misses): 0/4002ISIS: LSPIX validations (full/skipped): 216271/490412ISIS: LSP HT=0 checksum errors received: 0ctalkb#

@sh list

perhaps a singly linked list manager which displays globalpointer to the first element in each linked list as well as thenumber of members in each list.

ctalkb# sh listList 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 nonectalkb# sh list noneList 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 moParser modes:Name Prompt Top Alias Privilegeexec 0x60EFB294TRUE TRUEconfigure config 0x60EFABACTRUE TRUEinterface config-if 0x60EF7AECTRUE TRUEsubinterface config-subif 0x60EF7AECTRUE FALSEnull-interface config-if 0x60EFB368TRUE TRUEline config-line 0x60EF3F84TRUE TRUE

@sh parser unctalkb#sh parser unUnresolved parse chains: 40 40 198 198 322

@sh proc all-eventsctalkb#sh proc all-eventsQueue Notifications Event Name Pid 1 Process 61588410 Pool Grows 4 Pool Manager ct0 615A156C Log Messages 19 Logger ct0 615EE8A0 IPC inboundQ 11 IPC Seat Manager ct0 615EE934 IPC Zone inboundQ 9 IPC Zone Manager ct0

61642840 ARP queue 12 ARP Input ct0

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

ctalkb#sh prof dProfiling enabled

Block 0: start = 91, end = FFF, increment = 8, EXECTotal = 0System total = 9802ctalkb#sh prof tPROF 91 FFF 8PROFTOT 10065ctalkb#

@sh region (shows image layout)

displays the program layout for the uncompressed image.

ctalkb#sh regionRegion Manager:

Start End Size(b) Class Media Name0x07800000 0x07FFFFFF 8388608 Iomem R/W iomem20x20000000 0x21FFFFFF 33554432 Iomem R/W iomem0x57800000 0x57FFFFFF 8388608 Iomem R/W iomem2:(iomem2_cwt)0x60000000 0x677FFFFF 125829120 Local R/W main0x60008900 0x6123AC29 19079978 IText R/O main:text0x6123C000 0x6136A17F 1237376 IData R/W main:data0x6136A180 0x6152565F 1815776 IBss R/W main:bss0x61525660 0x677FFFFF 103655840 Local R/W main:heap

@sh region {address}

picking a random location within memory shows what segment thatspecific address falls under. same info can be gleaned from theroot command.

ctalkb#sh region a 0x07800000Address 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 iscompared with the previously stored checksum to ensure integrity.

ctalkb#sh sumNew checksum of 0x36D03E96 matched original checksumctalkb#

@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 framesto the specified destination:

ctalkb#test transmitinterface: Ethernet3/0total frame size [100]:1) To this interface2) To another interface9) Ask for everythingChoice: 2Encapsulation Type:1) Ethertype2) SAP3) SNAP4) SNAP (Cisco OUI)5) SNAP (EtherV2 OUI)6) Novell 802.3Choice: 1Protocol type:1) IP2) XNS3) IPX9) Ask for everythingChoice: 1

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

(in config mode)

@boot system rom

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

ctalkb(config)#boot system romThe '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 configurecommand '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 towrite it.

@ip slow-convergence

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

@ip tftp boot-interface

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

@loopback diag

all of these loopback commands allow you to loop the hardware atspecific points so that you can isolate hardware faults. e.g. thisis 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 specificprocess is on CPU before it reports debugging information. a relativelyeasy way to report which process is hogging. sh proc cpu is obviouslythe best way to track down cpu hogs while on the router, but this commandallows you to track down more insidious hogs.

00:13:18: %SYS-3-CPUHOG: Task ran for 308 msec (3/1), process = VirtualExec, 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 somesort of fatal process error. the default action of IOS is to have thisknob turned off and to crash the router upon the recognition of a fatalerror. this is done on a per-process basis. obviously, some processesare more critical than others and moving the offending process out of thescheduler won't really buy you any time or information.

@service internal

this is a really nifty command. turning it on in global configurationmode allows you to view some previously hidden commands. turn it onby 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 dependingon the amount of memory in the router (copying 128MB with varyinglink speeds. you do the math). it is important to note that thiscopying occurs before the router enters usable mode, so you basicallyhave added quite a bit of delay into the reload time. theexception-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 60373EBC603B6D2C 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 insightinto whats happening. i would prefer this command even though ithas been deprecated in favor of the filter-list command. reasoning:this command is more specific.

in router isis config:@partition-avoidance

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

Popularity: 6% [?]

Leia também:

Níveis de privilégio no IOS Cisco

Legalidade do Cisco IOS rodando no DynamipsRecuperando um IOS perdidoCisco IOS IP SLA tool

10 dicas “quentes” relacionadas ao Cisco IOSScript para automatizar comandos em switches Cisco…

Cisco alerta para falha grave de segurança na versão 12.4 do IOSImplementando Pequenas Redes com Cisco

Compreendendo a nomenclatura do IOSCisco IOS versão “estudante” - entre na briga para que a Cisco libere uma!Acoplando um Sistema de Aceleração - Juniper WX - a um Roteador Cisco via WCCPv2

[P&R] Cisco IOS x Cisco CatOSAuto-Segurança em roteadores Cisco

Script para auto-arquivamento das configurações de elementos de redeUsando o roteador / switch Cisco como um servidor DHCP

Este post foi postado Sunday, 17 de August de 2008 às 1:30 pm e está em Curiosidades, Artigos, Cisco. Você podeverificar qualquer resposta a este post através do feed RSS 2.0. Você pode ir até o final e deixar uma resposta. Pings nãosão permitidos.

9 Respostas para “Comandos não-documentados do Cisco IOS”

1. Marcelo Conterato diz: 17 de August de 2008 às 4:40 pm

Muito bom Marco, esses comandos “escondidos” são bem interessantes, vou testá-los

aqui no simulador. Valew!

2. Rodrigo C. Soave diz: 18 de August de 2008 às 11:35 am

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.

http://www.elemental.net/~lf/undoc/

http://www.madness.at/~mad/cisco_ios_udc.htmlhttp://ccie-lounge.blogspot.com/2007/06/undocumented-cisco-ios-commands.html

http://www.heinzulm.com/hu03.html

Abs

3. Marco Filippetti diz:18 de August de 2008 às 2:00 pm

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

4. Anderson diz: 18 de August de 2008 às 6:34 pm

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.

Abraços,Anderson

5. Wederson (CeBoLaRk) diz: 18 de August de 2008 às 6:57 pm

Muito legal o post…

5.

6. giorgio diz: 18 de August de 2008 às 11:15 pm

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

7. Sergio Abe diz: 19 de August de 2008 às 9:49 am

Esses comandos hidden são muito bons.

Segue mais um, com link do site da CISCO, com relação a um comando que pode serdado no prompt do roteador :

>ttcp

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

segue o link :

http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080094694.shtml

USING TEST TPC (TTCP) TO TEST THROUGHPUT

Contents

Introduction

Before You BeginConventions

PrerequisitesComponents UsedPreparing for the TTCP Session

Performing the Downlink Test (from the Router to the Windows PC)Obtaining the Results

Analyzing the ResultsPerforming the Uplink Test (from the Windows PC to the Router)

General GuidelinesRelated Information

Introduction

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 twosides display the number of bytes transmitted and the time elapsed for the packets to pass from oneend 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 twodevices with IP connectivity between them.

Before You BeginConventions

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

Prerequisites

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 connectionbetween 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 beused between any two devices.

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

customer-dialin-sj>

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:45333,24000

This edited output shows that the client is connected in V.90 at a 45333 bps downlink rate and a24000 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 linkthroughput.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.

C:\PROGRA~1\TTCPW>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 forthe 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 ina 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 topicsand 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 beforeyou begin the TTCP test.

customer-dialin-sj>ttcptransmit or receive [receive]:

transmit!— The AS5300 is the ttcp transmitter

Target IP address: 10.1.1.52

! — 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 ->10.1.1.52ttcp-t: connect (mss 1460, sndwnd 4096, rcvwnd 4128)

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

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 10.1.1.1

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 ->10.1.1.52 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 callsttcp-t: 0 sleeps (0 ms total) (0 ms average)

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

ttcp-r: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 connectionexperienced 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 theinformation from TTCP to calculate the bit rate (in kbps). Use the number of bytes received and thetransfer 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 thetransfer. 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.577kbps.

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 accessprocedure 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, theclient-side modem statistics to see what may have happened to impact performance (such as ECretransmits, 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 thereceiver, using the default parameters:

customer-dialin-sj>ttcptransmit 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]: delayedACK [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 theReadme file provided with the windows TTCP software for the appropriate syntax:

C:\PROGRA~1\

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

socket ttcp-t: connect

The IOS receiver reports the following results:

ttcp-r: accept from 10.1.1.52 (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 tothe 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 IOScommand 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 linkspeed. 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 ourexample above, although Microsoft Point-to-Point Compression (MPPC) compression was negotiatedon 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 thedownlink 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 sizesufficient to keep the pipe full. In the case of modem links, the default 4 KB window size is normallyadequate. 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 theWindows 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 notsupported by the Cisco Technical Assistance Center. Refer to the Readme file provided with the toolfor further installation and operating instructions.

8. Rodrigo Colen (BH) diz: 27 de August de 2008 às 3:07 pm

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

Marco,

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.

attRodrigo Colen

9. Marco Filippetti diz:27 de August de 2008 às 3:08 pm

Rodrigo, este sistema já foi implementado faz um tempinho… é o ícone “share this”,

que fica logo abaixo do post

Deixe um Comentário

Você deve estar logado para postar um comentário. Login »

Mandigo theme by tom.