sábado, 19 de janeiro de 2013

Montando um Home Lab (Parte 1 - VMWares)

Criar um Home Lab pode te poupar muitas horas de lab remoto durante a sua preparação. Não precisa criar um home lab completo, com gateways de verdade, PVDMs, E1s, telefones... claro, se você tiver condições, melhor! Mas montar um lab completo sai caro e toma tempo... a sugestão que eu dou é criar um lab simples, sem muito (ou nenhum) investimento, para poder testar algumas coisas. E dá para testar bastante coisa! No lab que vou mostrar nos próximos posts utilizaremos basicamente VMWare e GNS3/Dynamips.

Primeiramente, você precisa das ISOs de instalação do CUCM, CUC, UCCX e CUPS. Você pode comprar da Cisco uma versão para lab, ou usar métodos alternativos por sua conta em risco! hehehe... O caso do UCCX é um pouco mais complicado porque precisa de licença, precisa da ISO de instalação do Windows, etc. Para os outros servidores, existe uma forma de transformar um ISO de upgrade (que você pode baixar do site da Cisco) em "bootável". Veja aqui.

Fora as ISOs, você precisa de uma máquina relativamente boa. Mas não precisa exagerar! A minha por exemplo é um Intel QuadCore 2.66GHz, 8GB de RAM, rodando um Windows 7 64bits. E rodava bem... isso porque durante o seu lab, você não precisa subir as 4 VMs ao mesmo tempo. Sobe apenas as que você precisa e deixa as outras em Suspended. E a dica que eu dou também é usar processador da Intel. Já tive vários problemas rodando em AMD.

E finalmente, você vai precisar de um VMWare Workstation (que é pago... mas aí você dá os seus pulos! hehehehe), do GNS3 (que é gratuito e você pode baixar aqui), e de algumas IOSs.

Com tudo isso em mãos, vamos começar a montar o lab, que terá a seguinte topologia:

Nesse post falarei apenas do Site HQ, que vai ser basicamente subir os 4 servidores. Não vou entrar na parte de GNS3 ainda, senão vai ficar muita coisa.


1. Rede

Primeiro, você tem que decidir se vai por os servidores na mesma LAN da sua casa, ou se vai criar uma rede isolada dentro do seu computador. Eu acho mais legal colocar na LAN da sua casa, porque aí você pode colocar outros notebooks na rede e subir vários IP Communicators e tal, vai poder acessar os servidores via Wireless de um outro local... enfim, fica melhor!Para isso não precisamos fazer nada com relação a configuração de rede no VMWare. Mas como teremos os sites Branch1 e Branch 2 (esses sim criados como uma rede isolada dentro da sua máquina), vamos criar essas duas redes usando a ferramenta Network Editor, que vem junto na instalação da VMWare. Essa ferramenta tem essa cara:


Vamos colocar os servidores na VMnet0 (que está como Bridged, ou seja, vai usar a rede que está conectada na interface selecionada, entrando na LAN da sua casa), e criaremos a VMnet1 e VMnet2, cada uma em uma rede diferente, onde colocaremos o Branch1 e Branch2, respectivamente.
Para isso, em cada uma delas, selecione a opção Host-Only, habilite o DHCP e defina o IP da rede, como mostra abaixo:


No meu exemplo, defini como sendo 172.16.20.0/24 a rede da VMnet1 (Branch1) e 172.16.30.0/24 a rede da VMnet2 (Branch2).

Repare que o Windows criou 2 placas de redes virtuais. Atribua a elas os IPs 172.16.20.100 e 172.16.30.100, por exemplo:


Agora finalmente vamos começar a criar as VMs.


2. Criando as Máquinas Virtuais

Com a rede preparada, é hora de começarmos a criar as máquinas virtuais. Criaremos inicialmente 4 VMs, uma para cada servidor. No lab real, tem mais uma que é o CUCM Subscriber. Mas para o nosso home lab, ele não é necessário.

No VMWare Workstation, vá em File >> New >> Virtual Machine. Selecione a opção Custom (advanced) e depois Next.



Quando ele pedir para escolher o driver ou ISO de instalação, selecione a opção "I will install the operating system later", e clique Next.




O wizard vai pedir para você escolher o Sistema Operacional. Se for alguma versão antes da 8.6, escolha Linux >> Red Hat Enterprise Linux 4. Após a 8.6, o sistema operacional passa a ser Red Hat Linux 5. Mas como estamos montando um lab de CCIE, com os servidores na versão 7.0, vamos escolher o Red Hat 4.


Escolha um nome para a máquina, e um diretório para armazená-la. Veja se você tem bastante espaço em disco!


Deixe o número de processadores e core, como 1, e aloque 2048 MB de RAM para cada VM.


Selecione o opção "Use bridged networking" como Network Type, para que a VM utilize a LAN da sua casa.

 

Use o disco LSI Logic e crie um novo disco virtual do tipo SCSI com 80GB. Não aloque o espaço, deixe que a VM cresça sozinha... dificilmente vai chegar nos 80GB. E recomendo que divida o disco em arquivos de 2GB, no caso de você ter que copiar a VM para um HD externo que por acaso esteja formatado em FAT32 (já aconteceu comigo! hehe).

 

Pronto, a sua VM foi criada, e você vai vê-la na barra da esquerda. Clique com o botão direito nela e vá em Settings. Veja se a configuração está ok, depois clique em CD/DVD, marque a opção "Connected at power on", e selecione "Use ISO image file", selecionando o ISO de instalação.


Pronto, é só ligar a VM que ela já vai iniciar a instalação. Instale normalmente, como você faz no dia-a-dia. No caso das versões 8.x, é obrigatório você ter um servidor NTP, aí você pode usar um externo (ntp.br), ou subir um roteador no GSN3, como veremos nos próximos posts.

No caso do CCX é quase a mesma coisa, mas você deve selecionar como sistema operacional o Windows 2003 Server.

Nos próximos posts continuarei com a montagem desse Home Lab.

quarta-feira, 2 de janeiro de 2013

Instalando locales no CME

E ai pessoal!
Primeiramente, Feliz Ano Novo!!! Espero que 2013 seja um ano de muitas conquistas para você, assim como foi 2012 para mim!

Bom, começo o ano escrevendo sobre como instalar uma nova locale no CME a partir da versão 7.0. Você pode encontrar o procedimento completo neste link. Mas resumidamente, os passos são:

1. Baixe o pacote de línguas do CME do site da Cisco. É um arquivo ZIP com todas as locales disponíveis em formato TAR. Escolha os TARs que você deseja, e jogue na flash do roteador, dentro da pasta its/
copy tftp://x.x.x.x/CME-locale-xx_XX-Xxxxxx-8.6.2.4.tar flash:/its/

2. Defina o cnf-file como "perphone", dentro de telephony-service
telephony-service
 cnf-file perphone

3. Defina o cnf-file location na flash
telephony-service
 cnf-file location flash:

4. Defina a locale default do sistema.
telephony-service
 user-locale U1 load CME-locale-pt_BR-Portuguese-8.6.2.4.tar

Essa vai ser a locale default, definida na "user-locale 0". Dessa forma, todos os telefones estarão em Portugues. Se é isso que você deseja, pode parar por aqui. Mas caso você queira alguns telefones em outras línguas, execute os passos abaixo.

5. Defina as locales adicionais.
telephony-service
 user-locale 1 U2 load CME-locale-en_US-English-8.6.2.4.tar
 user-locale 2 U3 load CME-locale-ja_JP-Japanese-8.6.2.4.tar

Agora, definimos na "user-locale 1" a lingua inglesa e na "user-locale 2" a lingua japonesa.

6. Aplique as linguas em ephone-templates, e os templates nos ephones.
ephone-template 1
 user-locale 1

ephone-template 2
 user-locale 2

ephone 1
 ephone-template 1

ephone 2
 ephone-template 2

Atualize os arquivos CNF:
telephony-service
 create cnf-file

E resete os telefones.


Troubleshooting

Você não precisa adicionar nada no tftp-server, porque ele cria o binding automaticamente. Você pode verificar isso com o comando show telephony-service tftp-bindings:

tftp-server flash:/its/user_define_1_7905-dictionary.xml alias User_Define_1/7905-dictionary.xml
tftp-server flash:/its/user_define_1_7905-kate.xml alias User_Define_1/7905-kate.xml
tftp-server flash:/its/user_define_1_7921-dictionary.xml alias User_Define_1/7921-dictionary.xml
tftp-server flash:/its/user_define_1_7921-font.dat alias User_Define_1/7921-font.dat
tftp-server flash:/its/user_define_1_7921-kate.utf-8.xml alias User_Define_1/7921-kate.utf-8.xml
tftp-server flash:/its/user_define_1_7921-kate.xml alias User_Define_1/7921-kate.xml
tftp-server flash:/its/user_define_1_7960-dictionary.xml alias User_Define_1/7960-dictionary.xml
tftp-server flash:/its/user_define_1_7960-dictionary-ext.xml alias User_Define_1/7960-dictionary-ext.xml
tftp-server flash:/its/user_define_1_7960-font.xml alias User_Define_1/7960-font.xml
tftp-server flash:/its/user_define_1_7960-kate.xml alias User_Define_1/7960-kate.xml
tftp-server flash:/its/user_define_1_be-sccp.jar alias User_Define_1/be-sccp.jar
tftp-server flash:/its/user_define_1_g3-tones.xml alias User_Define_1/g3-tones.xml
tftp-server flash:/its/user_define_1_gp-sccp.jar alias User_Define_1/gp-sccp.jar
tftp-server flash:/its/user_define_1_ipc-sccp.jar alias User_Define_1/ipc-sccp.jar
tftp-server flash:/its/user_define_1_mk-sccp.jar alias User_Define_1/mk-sccp.jar
tftp-server flash:/its/user_define_1_SCCP-dictionary.utf-8.xml alias User_Define_1/SCCP-dictionary.utf-8.xml
tftp-server flash:/its/user_define_1_SCCP-dictionary.xml alias User_Define_1/SCCP-dictionary.xml
tftp-server flash:/its/user_define_1_SCCP-dictionary-ext.xml alias User_Define_1/SCCP-dictionary-ext.xml
tftp-server flash:/its/user_define_1_tags_file alias User_Define_1/tags_file
tftp-server flash:/its/user_define_1_tc-sccp.jar alias User_Define_1/tc-sccp.jar
tftp-server flash:/its/user_define_1_td-sccp.jar alias User_Define_1/td-sccp.jar
tftp-server flash:/its/user_define_1_rp-sccp.jar alias User_Define_1/rp-sccp.jar
tftp-server flash:/its/user_define_1_utf8_tags_file alias User_Define_1/utf8_tags_file
tftp-server flash:/its/user_define_1_rtl-sccp.jar alias User_Define_1/rtl-sccp.jar
tftp-server flash:/its/user_define_1_g4-tones.xml alias User_Define_1/g4-tones.xml


Obviamente, os arquivos devem estar na flash. O CME instala esses arquivos no passo 4/5. É automático, você não precisa descompactar o TAR manualmente

Router# sh flash | i user_define_1
178      62041 Jan 2 2013 12:48:52 +00:00 its/user_define_1_ipc-sccp.jar
186      69903 Jan 2 2013 12:48:56 +00:00 its/user_define_1_rp-sccp.jar
187      71837 Jan 2 2013 12:48:56 +00:00 its/user_define_1_tc-sccp.jar
188       2858 Jan 2 2013 12:48:54 +00:00 its/user_define_1_tags_file
189       4141 Jan 2 2013 12:48:54 +00:00 its/user_define_1_SCCP-dictionary.xml
190       6656 Jan 2 2013 12:48:54 +00:00 its/user_define_1_SCCP-dictionary.utf-8.xml
191      75004 Jan 2 2013 12:48:52 +00:00 its/user_define_1_gp-sccp.jar
192       1302 Jan 2 2013 12:48:50 +00:00 its/user_define_1_g3-tones.xml
193      61964 Jan 2 2013 12:48:50 +00:00 its/user_define_1_be-sccp.jar
194        736 Jan 2 2013 12:48:50 +00:00 its/user_define_1_7960-tones.xml
195      13326 Jan 2 2013 12:48:48 +00:00 its/user_define_1_7960-font.xml
196      23450 Jan 2 2013 12:48:48 +00:00 its/user_define_1_7960-dictionary-ext.xml
197      22811 Jan 2 2013 12:48:48 +00:00 its/user_define_1_7960-dictionary.xml
198       1820 Jan 2 2013 12:48:48 +00:00 its/user_define_1_7921-kate.xml
199     137616 Jan 2 2013 12:48:46 +00:00 its/user_define_1_7921-font.dat
200       1820 Jan 2 2013 12:48:46 +00:00 its/user_define_1_7905-kate.xml
201      20718 Jan 2 2013 12:48:46 +00:00 its/user_define_1_7905-dictionary.xml
202       1789 Jan 2 2013 12:48:58 +00:00 its/user_define_1_g4-tones.xml
203        636 Jan 2 2013 12:48:58 +00:00 its/user_define_1_CME-locale-pt_BR-Portuguese-8.6.2.4.tar.cfg
204     120131 Jan 2 2013 12:48:58 +00:00 its/user_define_1_rtl-sccp.jar
205       2839 Jan 2 2013 12:48:56 +00:00 its/user_define_1_utf8_tags_file
206      62041 Jan 2 2013 12:48:56 +00:00 its/user_define_1_td-sccp.jar
207       6557 Jan 2 2013 12:48:54 +00:00 its/user_define_1_SCCP-dictionary-ext.xml
208      61764 Jan 2 2013 12:48:52 +00:00 its/user_define_1_mk-sccp.jar
209       1820 Jan 2 2013 12:48:50 +00:00 its/user_define_1_7960-kate.xml
210       1886 Jan 2 2013 12:48:48 +00:00 its/user_define_1_7921-kate.utf-8.xml
211      60189 Jan 2 2013 12:48:46 +00:00 its/user_define_1_7921-dictionary.xml



Verifique se os arquivos estão ok na flash, e se os bindings do tftp foram criados. Caso esteja tudo ok, veja se o arquivo de configuração do telefone está com a linguagem correta. Esses arquivos ficam na flash (porque definimos nos passos 2 e 3), e tem o nome no formato SEP<MAC_Address>.cnf.xml. Para visualizá-los, faça:
Router# sh flash | i <MAC Address>
131       1475 Jan 2 2013 13:26:44 +00:00 its/vrf1/SEP0021A0D76E1B.cnf.xml
Router# more its/vrf1/SEP0021A0D76E1B.cnf.xml

No arquivo, você deve ver algo assim:
<userLocale>
<name>User_Define_1</name>
<langCode>pt_BR</langCode>
<winCharSet>utf-8</winCharSet>
</userLocale>


Outro comando útil para esse troubleshooting, é verificar se o telefone está conseguindo fazer o download dos arquivos via tftp. Use o debug tftp events.
Jan  2 13:50:25.671: TFTP: Looking for CTLSEP0021A0D76E1B.tlv
Jan  2 13:50:25.771: TFTP: Looking for ITLSEP0021A0D76E1B.tlv
Jan  2 13:50:25.891: TFTP: Looking for ITLFile.tlv
Jan  2 13:50:26.083: TFTP: Looking for SEP0021A0D76E1B.cnf.xml
Jan  2 13:50:26.087: TFTP: Opened flash:/its/vrf1/SEP0021A0D76E1B.cnf.xml, fd 14, size 1475 for process 30
Jan  2 13:50:26.091: TFTP: Finished flash:/its/vrf1/SEP0021A0D76E1B.cnf.xml, time 00:00:00 for process 30
Jan  2 13:50:28.703: TFTP: Looking for User_Define_2/td-sccp.jar
Jan  2 13:50:28.707: TFTP: Opened flash:/its/user_define_2_td-sccp.jar, fd 14, size 59183 for process 30
Jan  2 13:50:28.887: TFTP: Finished flash:/its/user_define_2_td-sccp.jar, time 00:00:00 for process 30

sábado, 22 de dezembro de 2012

Call Park no CME

Nossa, hoje me dei conta que o blog completará 1 ano em alguns dias. Mas certamente dessa vez eu não passarei o fim do ano escrevendo posts! hehehe

Hoje vou falar de call park no CME. Como dificilmente implantamos isso na vida real, esse foi um dos tópicos que me surpreendeu durante os estudos, devido a quantidade de detalhes que se pode configurar. O que eu sabia de Call Park era apenas o comando park-slot dentro de um ephone-dn e pronto, mas tem um monte de coisa que da para configurar.

Nesse post vou focar na versão 7.0 do CME, que é o que tem na prova. Na 7.1 tem algumas coisas mais, dentre elas o suporte a SIP Phones (na prova não vai cair Call Park para SIP, porque não é suportado), reservation-groups, directed call park, ...

Bom, começando do começo. Call Park é a feature de "estacionamento de chamadas", que tinha nos antigos PBX. A recepcionista, por exemplo, atendia uma ligação, fazia o park dela em um ramal XXXX, e anunciava pro chefe: "tem uma chamada no ramal XXXX". Aí o chefe ligava nesse ramal para capturá-la. No CUCM e CME temos essa feature, mas sinceramente, nunca vi ninguém usando na vida real... É mais fácil falar pro cara ligar depois! hehehe

Para configurarmos um ramal XXXX de park, simplesmente criamos um ephone-dn, por exemplo:

ephone-dn 10 dual-line
 number 3010
 name Call park
 park-slot

Agora vamos começar a ajustar esse nosso Call Park. A primeira coisa que podemos fazer, é definir alguns timers. Podemos definir que depois de "x" segundos que um cara estiver em park, um ring de lembrete será tocado no telefone da pessoa que estacionou a chamada. Aí digamos que queremos que esse lembrete ocorra por "y" vezes, e depois disso a chamada volte para quem fez o park. Caso o ramal esteja ocupado, ele vai tentar de novo depois de "s" segundos por "z" vezes. Nesse exemplo, o nosso ephone-dn ficaria assim:

ephone-dn 10 dual-line
 number 3010
 name Call park
 park-slot timeout x limit y recall retry s limit z

Agora, digamos que queremos que o ramal a ser notificado com um ring sobre uma chamada em park não seja o que fez o estacionamento, mas sim um um outro qualquer (por exemplo, o ramal 2001), aí faríamos:

ephone-dn 10 dual-line
 number 3010
 name Call park
 park-slot timeout x limit y notify 2001 recall

O cliente mudou o requisito de novo, e agora ele quer que quando o timeout/limit acabe, ao invés de a chamada voltar para quem fez o park, ela deve tocar no ramal 2050, e depois para o 2051 caso o 2050 esteja ocupado:

ephone-dn 10 dual-line
 number 3010
 name Call park
 park-slot timeout x limit y notify 2001 transfer 2050 alternate 2051

Obs: Podemos usar o alternate também como uma segunda opção do recall, ou seja:
ephone-dn 10 dual-line
 number 3010
 name Call park park-slot timeout x limit y notify 2001 recall alternate 2050

Bom, agora que estava todo mundo usando o call park a vontade, o cliente percebeu que muitas chamadas estavam se perdendo. Então ele quer que apenas a recepcionista no ramal 2000 consiga utilizar esse call-park. Aí utilizaremos o comando reserved-for:

 ephone-dn 10 dual-line
 number 3010
 name Call park
 park-slot reserved-for 2000 timeout x limit y recall
Mas mesmo assim, descobriram que o pessoal continua conseguindo fazer park da chamada. Só que ao invés de eles pressionarem o softkey Park para isso, eles descobriram que se eles dessem um transfer para o ramal 3010, a chamada era estacionada! Olha só que usuários safadinhos! Mas para isso podemos bloquear esse comportamento configurando dentro do ephone:

ephone X
 transfer-park blocked

Com isso, abordamos quase tudo de call park no CME, tem mais coisa, mas isso é o que eu me lembro! hahaha... Só tem mais uma coisa importante para se dizer. Por default, se existir por exemplo um ramal 1003 e um park-slot 3303, ele sempre vai tentar usar esse por causa do match dos últimos 2 dígitos. Se existisse um outro park-slot 3302, ele seria usado como segunda opção. Para desligar esse comportamento, faça:

telephony-service
 call-park select no-auto-match


Eu recomendo que façam vários testes com Call park, porque são muitos detalhes, como tudo no CME. A melhor coisa para se fazer ao estudar CME é ler o Admin Guide inteiro e ir testando feature por feature. Tenho várias páginas de anotações de CME no meu caderno (como essa), e aos poucos vou postando.

sábado, 1 de dezembro de 2012

Dial-Peer Matching

Esse é um tema fácil, mas um tanto confuso. O match de dial-peer é extremamente importante para você definir a sua call leg de entrada e de saída no roteador, e fazer certo o seu dial plan.
Toda chamada que passa pelo gateway (seja ela voip ou pots) deve ter essas duas pernas: uma entrada e uma saída. Para entender melhor o que é isso, se coloque no lugar do roteador. Imagine uma chamada vindo da PSTN e tocando no IP Phone. Para o roteador, a perna que vem da PSTN é a entrada, e a que toca no telefone (ou seja, a que manda para o CUCM) é a saída. Já em uma chamada onde o IP Phone origina e toca na PSTN é ao contrário, temos uma perna de entrada que é a que vem do CUCM, e uma de saída que vai para a PSTN. Toda chamada para completar com sucesso precisa dessas duas dial-peers.
Para configurar uma dial-peer para dar matches de entrada ou saída, usamos os comandos incoming called-number, answer-address, destination-pattern e ports.

Dial-Peer de Entrada

O roteador possui 4 maneiras de verificar se uma chamada específica teve match em alguma dial-peer de entrada,  analisando o número de origem (ANI, ou Calling Number) ou destino (DNIS, ou Called Number) dessa chamada, ou a voice port que foi usada para recebê-la. E o roteador analisa nessa ordem:

1. Compara o número Destino com o incoming called-number
2. Compara o número de Origem com o answer-address
3. Compara o número de Origem com o destination-pattern
4. Verifica a Voice Port que recebeu a chamada

O que geralmente fazemos na vida real é logo de cara forçar uma dial-peer de entrada do tipo pots e do tipo voip. Assim:

dial-peer voice 1 pots
 incoming called-number .

dial-peer voice 2 voip 
 incoming called-numer .

Com isso, toda chamada que entrar da PSTN vai bater na dial-peer 1 como entrada (e aqui faria sentido você colocar o comando direct-inward-dial dentro da dial-peer); e toda chamada que entrar do CUCM vai bater na dial-peer 2 como entrada (e aqui faria sentido você definir os codecs).

Mas e se eu quiser forçar uma dial-peer de entrada que tem como destino um ramal específico para, por exemplo, chamar uma aplicação ao invés de mandar para o CUCM (sabe usamos isso, né? No MVA!). Aí eu poderia forçar assim:

dial-peer voice 4444 pots
 service mva   
 incoming called-number 4444
 no digit-strip

Ah, mas e se eu quero dar match na entrada usando o número de origem, e não de destino? Aí podemos usar o answer-address ou destination-pattern (embora esse último seja um pouco complicado, já que usaremos ele também para dial-peer de saída). Mas veja que o roteador só vai partir para essa análise caso a regra 1 não tenha sido atendida.
Caso a chamada entrante não dê match em nenhuma das 3 primeiras regras, o roteador vai analisar a voice port (isso se aplica somente a dial-peers pots). Então se você tem eventualmente uma dial-peer de saída apontando para port 0/0/0:0, e a chamada entrou por essa mesma porta, o roteador pode considerar essa dial-peer como a de entrada. Se houver mais que uma dial-peer apontando para a mesma voice-port, o critério de desempate vai ser a dial-peer adicionada primeiro na configuração.
E por fim, se nenhuma das 4 regras foi atendida, finalmente o roteador vai usar a dial-peer default do sistema que é a 0. Essa dial-peer não é vista na configuração, não é configurável, e portanto queremos evitá-la a todo custo!

A dica que dou é sempre usar o incoming called-number nas suas dial-peers de entrada (a não ser que um requisito maluco da prova te obrigue a usar o answer-address). É importante você ter bastante controle da sua entrada para eventualmente aplicar regras de translations nela (que falarei mais em um outro post), e também para você não cair em caso de codec mismatch e tal, especialmente quando for implementar CUBE, onde o conceito de match de dial-peer de entrada é fundamental.


Dial-Peer de Saída

A saída é bem mais fácil, pois o roteador utiliza um único comando para isso, que é o destination-pattern, velho conhecido de todos nós. E a saída é definida pelo comando port (no caso de dial-peer pots) ou session target (no caso de dial-peer voip).O que tem mais de interessante para falar nas dial-peers de saída é como os critérios de desempate são feitos.

A regra é que por default, quando um número destino da match em vários destination-patterns, de várias dial-peers, o critério de desempate é pelo match mais específico. Porém, temos duas situações aqui:

1. Quando a dial-peer de entrada é do tipo DID (quando colocamos o comando direct-inward-dial, presente apenas em dial-peers pots), a análise dos dígitos na saída é feita com o bloco inteiro dos números. Ou seja, se o roteador recebeu 32324444, ele vai analisar toda essa string de uma só vez. Logo, uma dial-peer com destination-pattern 32324444 vai dar match, enquanto uma dial-peer com destination-pattern 32324, por exemplo, não vai dar match. Esse caso se aplica, portanto, apenas nas chamadas entrantes da PSTN.

2. Quando a dial-peer de entrada não é do tipo DID, o roteador passa a analisar os números dígito a dígito na saída. Então se, por exemplo, o roteador receber os mesmos 32324444, agora na saída a dial-peer com destination-pattern 32324 dará match antes da dial-peer com destination-pattern 32324444, e logo será usada. E se houver uma terceira dial-peer com destination-pattern 32324..., ela também não será usada porque é menos específica que a 32324444 (aí sim entra o critério de desempate da mais específica).

Você pode também alterar a forma como o roteador faz o seu critério de desempate das dial-peers com o comando dial-peer hunt. O valor default é o 0, mas você pode configurar qualquer um dos 7 abaixo:

  0 - Longest match in phone number, explicit preference, random selection.
  1 - Longest match in phone number, explicit preference, least recent use.
  2 - Explicit preference, longest match in phone number, random selection.
  3 - Explicit preference, longest match in phone number, least recent use.
  4 - Least recent use, longest match in phone number, explicit preference.
  5 - Least recent use, explicit preference, longest match in phone number.
  6 - Random selection.
  7 - Least recent use.


Debugs úteis

Um dos melhores, aliás, o melhor debug para ver matching de dial-peer é o debug voip dialpeer. Mas outros comandos também são úteis:

debug voip dialpeer

show voice call status ! -- mostra a dial-peer de entrada e saída de cada chamada ativa no roteador

debug voice ccapi inout ! -- Mostra o match de entrada, saída, número de origem, destino, debug muito útil em qualquer situação. Só que ele gera muito output.

show dialplan number XXXXX ! -- onde XXXXX é o número de destino. Ele mostra em quais dial-peers a chamada dará match na saída. Ótimo para testar se a sua dial-peer está dando match.

show dial-peer voice summary ! -- mostra o tipo de hunt configurado e o resumo das dial-peers criadas

show run | sec dial-peer !-- Muito útil! Mostra o show run apenas das suas dial-peers

domingo, 18 de novembro de 2012

Captura de pacotes (CUCM | Voice Gateway | IP Phone)

A novidade do dia é que mudei a cor do blog, e aumentei a largura do quadro de postagens, acatando sugestões que recebi. Realmente, acredito que a tela branca seja menos cansativa para leitura. Embora o conteúdo não ajude muito! hehehe

Semana retrasada participei de um evento do TAC da Cisco, e a engenheira Michelle Jardim (primeira CCIE Voice que eu conheço que passou na primeira tentativa) nos apresentou algumas formas de fazer capturas de pacotes no CUCM e no Router, para serem analisados em um Wireshark da vida. Eu já precisei fazer essas capturas várias vezes nos meus troubleshootings, e quem não sabe o procedimento, sugiro que leia. Capturas de pacotes são ótimas para troubleshootings, especialmente naqueles que você tem que provar por A + B para o cliente que o CUCM ou gateway não está recebendo determinados pacotes, colocando a culpa no cara de redes/firewall! hahaha... Geralmente esse pessoal não confia muito nos traces do CUCM, mas quando você mostra no Wireshark, aí não tem erro! hehehehe
Outra situação bem comum de utilizar isso é em troubleshooting de One-Way Audio ou No Audio, para saber onde os RTPs estão parando.

Lógico, esse post não se aplica muito ao exame do CCIE Voice em si. Afinal, se você estiver na prova e tiver que fazer um troubleshooting desse nível, é porque tem alguma coisa muito errada nos seus métodos! hahaha... mas certamente um dia você vai precisar na vida real.


1. Captura no CUCM

O jeito mais fácil de fazer capturas no CUCM é simplesmente capturar tudo que passa pela interface. Isso é feito via CLI através do comando:

utils network capture eth0 file capture count 100000 size all

Com esse comando, o CUCM vai armazenar no arquivo capture.cap tudo o que passar pela interface eth0. Para parar a captura, aperte Ctrl C. Então, para rodar essa captura, execute o comando via SSH, reproduza o problema e depois pare com o Ctrl C.

Para listar os arquivos de capturas disponíveis no servidor, utilize:

file list activelog platform/cli detail

Ele vai listar todos os arquivos do diretório, mostrando a data de criação. Escolha o arquivo desejado e faça o download dele via SFTP com o comando

file get activelog platform/cli/capture.cap

O software que costumo usar como SFTP Server é o FreeFTPd (http://www.freesshd.com/freeFTPd.exe). Ele é free (como vocês já devem ter percebido), e o melhor que tem... mas cuidado ao utilizá-lo como ferramenta de backup do CUCM, porque existem alguns bugs conhecidos e a Cisco não o recomenda mais para essa finalidade. Mas para baixar coisas do CUCM via CLI, é perfeito.


2. Captura no IOS

Para capturar pacotes em uma interface do roteador, defina um profile de captura, por exemplo: 

ip traffic-export profile test mode capture
 bidirectional
 length 512

E aplique na interface desejada:
interface fa 0/0
 ip traffic-export apply test size 200000
0 
Antes de começar a captura, recomenda-se limpar o buffer:
traffic-export interface fa 0/0 clear
Inicie a captura com o comando (no modo enable):
traffic-export interface fa 0/0 start
Após reproduzir o problema, pare parar a captura com o comando:
traffic-export interface fa 0/0 stop
Agora é só exportá-la via TFTP ou FTP:
traffic-export interface fa 0/0 copy tftp:

Address or name of remote host []? X.X.X.X
Capture buffer filename []? cisco.cap

3. Captura no telefone

Bom, no telefone é de boa, né? Você tem que espetar o seu notebook com um Wireshark na PC Port do IP Phone, e habilitar a opção Span to PC Port do telefone em questão. Com isso, o telefone vai espelhar todo o tráfego para o PC, que vai coletar os pacotes.

E pronto. Agora temos a captura no IP Phone, CUCM e Gateway, ou seja, o caminho completo. Aí é só abrir os arquivos no Wireshark e fazer as suas análises.

sexta-feira, 2 de novembro de 2012

Missão: CCIE Voice

Como prometi no post anterior, vou comentar um pouco sobre como foi a minha preparação para o CCIE. Quando eu estava começando, lia blogs e blogs sobre pessoas postando as suas experiencias, estratégias, métodos de estudo. E é exatamente o que farei agora. E o primeiro conselho que dou é: não siga as estratégias alheias! hehehe
Então o que vou escrever aqui não necessariamente se aplica a você. Leia sim posts sobre pessoas relatando a sua saga, mas não tome uma como um caminho ideal a seguir, mas sim pegue o melhor de cada uma para montar o seu próprio caminho. Cada pessoa é cada pessoa, e você tem que descobrir como é a sua melhor forma de trilhar o percurso, conciliando trabalho, vida pessoal e estudo.

Senta que lá vem história . . .


Bom, antes de começar o CCIE, você tem que ter ciência se vai poder terminá-lo. Não adianta nada comprar equipamentos e materiais de estudo, no impulso do momento, sendo que não vai ter tempo de estudar, não vai querer se sacrificar um pouco, e principalmente, não vai ter grana.
O material é caro, e mais caro que isso são as tentativas. Estime mais ou menos 7 mil reais por tentativa (1.500 dolares da prova, 1.500 dolares da passagem e uns 500 dolares com gastos de hotel, alimentação e taxi, sem muito luxo). E saiba que as chances de passar na primeira são virtualmente 0. Claro, pode ser que você seja uma exceção, mas não conte com isso ao estimar os seus gastos. A média de aprovação no CCIE Voice, se não me engano, é de 3,6 tentativas. Então tenha dinheiro para pelo menos umas 3 ou 4 (21 a 28k reais). Se passar de primeira ou segunda, lucro seu, e você vai lá se acabar na Best Buy quando passar! hehehe
Quanto aos materiais de estudo, eu usei os da IP Expert. Recomendo que ache um parceiro de estudo para rachar, senão fica muito caro (não me lembro o valor, e deve ter mudado também). E caso você não tenha um lab completo em casa, vai precisar de alugar lab remoto na ProctorLabs (ou outra empresa). Apesar do custo alto, recomendo que alugue o rack, e não passe muito tempo tentando montar o seu completo. Cada sessão de 8 horas custa 25 dolares (mas fique de olho nas promoções que eles lançam toda hora). No meu caso, usei cerca de 70 sessões. Para o lab remoto você vai precisar de ter pelo menos 3 telefones 7965/7970/7975 (de preferência 4, mas se não conseguir, pode usar 1 IP Communicator), 1 telefone 7960 para a PSTN, 1 switch PoE e um roteador para fechar a VPN (a lista de modelos suportados estão no site da Proctor Labs. Mas num adianta pegar um pau véio 2600 que num vai rolar).
Por isso que um apoio da empresa é sempre muito bem vindo... bancar o CCIE do próprio bolso é insano! Então a primeira coisa que você deve fazer quando decidir entrar nessa é ver no que a sua empresa pode te ajudar (inclusive com tempo de estudo, senão também num adianta nada).

Com a grana reservada, diposição para se sacrificar e tempo, é hora de começar! Eu comecei a minha jornada em Dezembro do ano passado, aproveitando que o movimento no trabalho estava mais tranquilo. Nas horas que conseguia, ficava assistindo aos vídeos do Internetwork Expert (acho que foi o único material do INE que eu usei, pois eu tinha uma conta que havia rachado com uns amigos). Os vídeos foram um ótimo começo para mim... bem tranquilo, estudava quando dava, onde dava, sem muita pressão. Quando tinha um tempo, me aprofundava em alguns tópicos lendo os Guides da Cisco ou fazendo testes nas minhas VMs em casa... E comecei a escutar no carro também os Audio on Demand da IP Expert, da ex-instrutora Amy Ryan. Esses áudios são bem tranquilos de ouvir, bem fáceis de entender, e você acaba aproveitando um tempo que seria morto, como no trânsito. E a voz dela é bem agradável também! hehe
Isso durou mais ou menos dois meses. Nesse meio tempo eu comecei a escrever esse blog, o que foi muito bom para mim. Durante os estudos com os vídeos/guides, eu costumava tomar muita nota em um caderno. Foi aí que eu tive a ideia de começar a passar algumas dessas notas para o blog. Recomendo! Quando você escreve em blog, apesar de tomar muito do seu tempo, você é obrigado a pesquisar um pouco melhor aquilo, fazer uns testes para ver se o que você tá falando está certo, e me ajudou a fixar melhor alguns conceitos, como os de QoS, que foram os primeiros posts e nunca mais esqueci.

Ao término dos vídeos, acho que no final de janeiro, me bateu um certo desespero, porque tive que sair da zona de conforto e começar a pegar mais firme. Porque até então, assistir uns videozinhos com o cara explicando tudo para você é muito fácil! hehehe... Comecei então a estudar o Volume 1 dos Workbooks da IP Expert. Esse volume 1 são vários labs curtos, fáceis, e que dão mais a base de todo o negócio. Mas percebi que mais importante que praticar os labs, era você entender o conceito por trás de cada questão. Nesse momento, você não tem que se preocupar com estratégia de prova, velocidade e tal. Precisa entender o negócio. Mas entender mesmo, de cabo a rabo. Então o volume 1 serve mais como um guia de estudo... você tem que saber fazê-lo, mas a cada capítulo, você tem que se aprofundar mais no assunto. Um exemplo: Lab de gatekeeper. Não basta você configurar o gatekeeper e fazer 2 sites se falarem... tem que pensar: "ah, mas e se eu configurar 2 zones diferentes? e se eu fizer com uma zone só usando tech-prefix? e se eu usar VIA zone? E se eu configurar assim, como fica o meu output do sh gatekeeper endpoints? E se eu usar VIA, como fica o sh gatekeeper calls? Mas por que eu vejo 2 call legs?". Entende? É muito mais do que resolver uma questão. Então eu estudava o volume 1 junto com guides da Cisco, e no final eu não fiz nem se quer uma sessão de lab para esse workbook. Eu respondia tudo escrevendo mesmo, escrevendo script no caderno e tal. No máximo simulava alguma coisa no meu lab em casa, usando VMWare e GSN3, por exemplo os labs de RSVP, que eu nunca tinha configurado.
Ah, um detalhe importante sobre guides. Muitos dizem que você tem que ler o SRND e decorá-lo de ponta a ponta. Eu não concordo... você tem que ter uma noção do que tem nele e tal, mas eu não cheguei a ler o SRND. O que eu li de cabo a rabo, e recomendo fortemente é o feature guide do CUCM e o admin guide do CME. Esse último em especial é muito bom que leia e teste tudo, porque tem umas coisas de CME que eu pelo menos nunca nem tinha ouvido falar.

Bom, essa minha luta com o Volume 1 foi até maio, ou seja, 3 a 4 meses. Acho que foi o período que eu mais aprendi coisas novas, e que, consequentemente, o estudo mais fluiu. Nessa fase você fica super empolgado, eu ficava até de madrugada estudando (porque gosto mais de estudar a noite), finais de semana, feriados... e aí em Maio, quando acabei de estudar o volume 1 e todos os itens do Blueprint, e tirei 1 semana de "férias", e viajei para Fortaleza com a minha namorada! hehehe... dar aquela relaxada! =P
Voltei de lá na pegada de começar o Volume 2. A essa altura, eu já tinha marcado o meu Bootcamp para Julho, e a minha prova para Setembro. Eu sabia que tinha 2 meses para o bootcamp, e nesses 2 meses eu precisaria destruir o Volume 2, para chegar preparado no curso. Nessa época a Dimension Data me ajudou bastante, me dando todas as sextas-feiras livres para estudar. Então foram 2 meses estudando de sexta, sábado e domingo, e mais alguns dias de folga que acabei pegando. Até o dia 1 de julho eu tinha feito cada um dos 10 labs do volume 2 pelo menos 2 ou 3 vezes. Eu costumava dar uma lida em 2 labs durante a semana (de segunda a quinta), e sexta, sábado e domingo eu fazia eles. A cada lab eu ía aprendendo coisas novas, e procurava também me aprofundar em alguns pontos (se necessário) ao longo da semana seguinte. Foram 2 meses super intensos e cansativos. Mas eu ficava satisfeito quando conseguia terminar o lab dentro da sessão de 7h45min da ProctorLabs.O objetivo maior do Volume 2, para mim, é você definir uma estratégia sua. Tem gente que recomenda usar o Device-Based Approach (procure no youtube, vale a pena), tem gente que acha melhor fazer por tecnologia. Eu fiz meio que uma mescla dos dois... mas acho que estratégia é um ponto muito pessoal, e cada um tem que bolar a sua. Num existe uma receita de bolo. A Device-Based approach acho que é a mais eficiente mesmo, mas eu pelo menos não consigo fazer a prova usando ela. Tem gente que consegue... então depende muito.

Até que chegou Julho e eu fui para San Jose, fazer o Bootcamp. Posso dizer que o que mais me ajudou para a prova foi esse Bootcamp. Lá você fica 2 semanas completamente imerso naquilo, sendo instruído por um cara muito, muito foda que é o Vik Malhi. Aprendendo formas muito mais rápidas de configurar as coisas e tal. Na primeira semana do curso foi mais teoria, e a segunda era só lab. Se você pensa em fazer esse curso, aconselho que vá tecnicamente preparado... você tem que ir já com um conhecimento muito bom de cada vírgula do blueprint. Isso porque o instrutor não vai te pegar na mão e ensinar a configurar um Device Pool, por exemplo... ele vai te falar como é a forma mais rápida de configurar o Device Pool sem ter que resetar os telefones. Saca? É muito mais focado na prova em si.
Depois do Bootcamp eu peguei 1 mês de férias (mês de agosto inteiro) para estudar. Aí eu marquei labs de segunda a sábado, e descansava domingo. Confesso que na metade do mês já estava pedindo água! hahaha... não conseguia mais ver um Call Mananager na frente!!! hehehe... Tinha dia que eu começava a sessão e simplesmente não conseguia fazer nada, não conseguia mais pensar naquilo... Aí eu parava, dava uma descansada e depois retomava. Ou largava mão de fazer lab aquele dia, e estudava algum item do blueprint, ou fazia alguns testes de troubleshooting.

Chegando no dia da prova, num fatídico 6 de Setembro, estava muito nervoso. Em RTP a prova começa às 7h15, e o candidato deve chegar umas 7h. Então acordei às 5h para sair às 6h, e não consegui pregar os olhos antes das 3h! haha... Cheguei lá bem cansado, e isso me deu um certo desespero. Na entrada, quando os candidatos ficam sentados no sofá esperando o Proctor, fica um silêncio mortal, e esse momento acho que é o pior do dia. Ainda bem que fui com um amigo, e ficamos conversando, o que me ajudou a relaxar um pouco. O proctor David chegou, passou um briefing do dia, e começamos o lab. A adrenalina era tanta que o sono nem pesou. Então se você for e não conseguir dormir um dia antes, não se preocupe... você definitivamente não vai sentir sono e não vai estar menos concentrado por causa disso! hehehe
No lab eu senti algumas dificuldades. Por exemplo, o terminal que eles te disponibilizam não faz copy/paste com o botão direito do mouse, como no Putty. O atalho Windows + D para exibir o Desktop não funciona... então essas pequenas coisinhas que você está acostumado no seu home lab acabam atrapalhando. E outra coisa é o endereçamento IP, que é diferente dos labs da ProctorLabs também... mas de resto, o lab foi tranquilo. Não ocorreu nenhum bug na minha prova, e consegui terminar ela com bastante tempo para revisar. Saí de lá com a impressão que havia passado. Porém, no dia seguinte recebi o resultado e FAIL. Até hoje não sei exatamente onde perdi tantos pontos na prova...
Isso é bastante desanimador. Não tanto por não passar, mas sim por ter que voltar ao Brasil e começar tuuudo denovo. Chegando aqui, marquei a segunda tentativa para a data mais próxima que consegui, no dia 23 de outubro. E fiquei 2 semanas sem estudar absolutamente nada. Depois comecei a fazer uns labs nos finais de semana. Só nas duas semanas que antecederam a prova que a Dimension Data novamente me deu vários dias de folga, e pude ficar 14 dias estudando direto, para retomar a velocidade.
Embarquei para os EUA no dia 21, descansei dia 22 e fiz a prova no dia 23. Novamente, não consegui dormir muito bem na noite anterior, mas isso não me preocupou muito porque sabia que não me atrapalharia no exame. E foi a mesma coisa. Acordei cedo. Silêncio mortal. Proctor. E a prova começou. Dessa vez fiz o lab mais tranquilo... eu sabia que o Windows + D num ía funcionar, e que o jeito certo de dar copy/paste era com o Shift + Insert. Já sabia o esquema de endereçamento IP, já sabia como a prova era estruturada, como vinham as tabelas. Então nesse sentido, a segunda tentativa foi bem mais tranquila. Terminei a prova agora com a certeza que tinha passado... mas ainda assim estava receoso, porque você nunca sabe como a sua prova será corrigida.
Voltei para o hotel acabado de cansado. É engraçado porque quando você termina a prova, parece que tomou uma surra daquelas... fica com o corpo todo dolorido. Até as minhas pernas doíam como se eu tivesse corrido quilometros! Bem estranho... Mas nesse dia dormi cedão. E no dia seguinte fiquei no hotel a manhã toda apertando F5, esperando o resultado da prova! Passou 9h, 10h, 11h e nada, e foi batendo o desespero. Até que às 11h10 chegou o e-mail, e o meu coração foi parar no teto. Mas a minha cabeça soh explodiu mesmo quando vi o resultado de que havia passado!
É esse o momento mais foda, que você sente um peso gigantesco saindo das suas costas, e uma sensação de alívio absurda. É esse momento que te faz pensar que todo o sacrifício valeu a pena.

Se você está pensando seriamente em tirar o CCIE, e viu que tem condições e vontade de ir até o fim, cara... vá em frente! Vai que no final vale a pena!

Boa sorte!

quinta-feira, 25 de outubro de 2012

CCIE Voice #37170

Após quase 1 ano de muito estudo, mais de 500 horas de lab, 2 semanas de BootCamp e guides lidos e relidos, finalmente completo essa jornada do CCIE Voice. Fiz a prova no dia 23 e recebi ontem a notícia de que havia sido aprovado. É um momento único, uma sensação indescritível de alívio e missão cumprida. Só quem já passou por isso mesmo para saber!
Não posso deixar de compartilhar aqui no blog o ocorrido, e agradecer a todos pela torcida. Nesse post não vou falar sobre a prova em si, mas sim agradecer as pessoas importantes que fizeram parte disso. Depois faço um outro post falando mais da prova e da minha preparação. Obviamente, não quebrarei nada do NDA (non disclosure agreement).
O CCIE não é um projeto que você conduz sozinho. Quando você decide se dedicar para essa certificação, deve ter consciência que se sacrificará muito por isso. E não só você se sacrificará, mas as pessoas com quem convive. Você vai privar muito do seu tempo que passaria com esposa/namorada, filhos, familiares e amigos para ficar dias trancado num lab durante 8 horas, muitas vezes sem nem almoçar/jantar. Vai passar finais de semanas inteiros estudando (muitos!), ou mesmo vai tirar 30 dias de férias para ficar todos os 30 dias focado (como foi o meu caso). Vai também tirar dias de folga do trabalho para estudar, sobrecarregando o time. Então, é necessário realmente muito apoio e compreensão das pessoas que te rodeiam.
Por isso, primeiramente, gostaria de agradecer a minha namorada, que me apoiou desde o começo e entendeu a importancia disso para a minha vida. Certamente, sem o apoio e compreensão dela, não teria tido forças para ir até o fim. Acredito que ela tenha sido quem mais sofreu com a minha ausência. Agradeço também aos familiares, ao meu pai, irmã, cunhado (também CCIE), ... por todas as não-idas a eventos familiares.
Agradeço os meus colegas de trabalho, principalmente os meus chefes, por conseguirem aprovar o custeio de todo o processo, e por me darem tempo para estudar. A Dimension Data realmente foi uma mãe!!! Poucas empresas fariam isso por seus funcionários, sendo que ela nem precisa de um novo CCIE na companhia, por conta da auditoria da Cisco (é claro que para uma integradora, quanto mais melhor). E agradeço muito o pessoal da área que seguraram as pontas fodamente enquanto o bonitão aqui ficava estudando! ehauehauehaue
Agradeço os clientes, um em especial que me emprestou um roteador para que eu pudesse estudar! Roteador este que foi fundamental para que eu pudesse utilizar o lab remoto da Proctor Labs. E aos demais clientes (todos!) por sempre estarem torcendo por mim e me incentivando.
Ao pessoal que se preparou para a prova junto comigo (ainda que alguns nem consigam ler essa mensagem em Português! hahaha!), ao Vik Malhi, instrutor da IP Expert (FODA!). Aos leitores do blog, que para a minha surpresa, descobri que eram muitos! Bom, não muuuuitos, mas mais do que eu imaginava. E a todos os amigos que fizeram parte desse projeto.
E finalmente agradeço a minha mãe, que infelizmente não está mais aqui para presenciar esse momento, mas certamente estaria bastante orgulhosa do filho. E orgulhosa de si mesma, por ter quase que me obrigado a fazer um tal cursinho de Net Academy para uma tal certificação de uma tal empresa chamada Cisco em meados de 2002. Quem diria que isso iria me levar tão longe! hahaha
É isso aí galera, agora é relaxar e voltar a vida normal. Amanhã, ou hoje, ou algum outro dia eu posto mais sobre a minha preparação. Pretendo continuar com o blog, porém não mais focado na prova em si... espero que o que eu tenha postado até hoje ajude alguém no seu CCIE.

Valeu!!

Bruno Nonogaki, CCIE #37170