Henrique Moura, CCIE #44884

Pessoal, depois de longos meses sem atualização no Blog (desculpa gente, mas dá uma preguiiiiça! ehuaheuaheua), vou finalmente fazer um post! O Henrique Moura, engenheiro da Wittel, foi o primeiro brasileiro a passar no lab da prova nova do CCIE, agora chamada de Collaboration. Parabéns Henrique!!!

################################################################################

Segue meu breve depoimento sobre a minha jornada do CCIE Collaboration e espero inspirar futuros CCIE's, assim como os que já postaram no seu blog me inspiraram.
Eu comecei por acaso na carreira Cisco, recebi um e-mail há uns 7 anos atrás para fazer o treinamento do CCNA e eu não fazia nem idéia do que era mas, felizmente, eu gostei dessa área e, desde então, fui me certificando e me especializando na área de voz.
Em 2013 eu queria focar no CCIE mas, como eu estava viajando a trabalho não tive a oportunidade, foi então que eu planejei quais seriam os meus próximos passos para alcançar o CCIE.
- Me preparar financeiramente (todo mundo sabe que não é barato essa jornada)
- Conciliar os estudos com o trabalho (aproveitar o tempo que eu ficava sozinho no hotel para estudar) 
- Foco, Disciplina e Determinação (para mim a pior parte pois tive que aprender a abrir mão de muitas coisas para alcançar meu objetivo)
Após esse planejamento comecei estudando para o CCIE Voice, fiz o Written Voice, porém não tive tempo de realizar nenhuma tentativa do LAB Voice, pois eu não estava conseguindo me organizar para praticar os Workbooks do IPExpert.
Conversei com meus chefes e disse que eu gostaria de voltar a trabalhar em SP para poder me dedicar ao laboratório e foi então que apareceu um projeto enorme em SP e  fui chamado para ser o responsável pelo mesmo.
Decidi comprar todos os equipamentos do Collaboration, pois eu estava tendo muitos problemas em alugar labs, foi então que eu decidi comprar praticamente 90% dos equipamentos idênticos ao blue print do Collaboration.
Assim que terminei de montar o lab comecei a praticar todos os tópicos dos blue print e ler manuais sobre cada tópico para me aprofundar e realizei o Written do Collaboration em maio de 2014.
Por ironia do destino no projeto que eu estava conheci uma pessoa que estava mudando para o CCIE Collaboration e essa pessoa me apresentou outras pessoas e assim formamos um grupo de estudos de 5 amigos e o mais divertido era que cada um era de um lugar do mundo. Então era um pouco complicado conciliar os fusos horários mas graças a Deus todos estavam sempre dispostos a ajudar uns aos outros.
Apesar de não conhecer pessoalmente o Luciano Tamarozzi, ele escreveu uma frase que sempre foi uma grande verdade durante essa minha jornada: "Não estude sozinho procure pessoas que estão estudando para compartilhar experiências, isso me ajudou muito. E não desanime quando falhar, mas sim aprenda com o erro."
Agora voltando um pouco mais para a realidade, pois ler as trajetórias dá a impressão que foi tudo fácil, mas não foi. Não conheço nenhum CCIE que não passou por nenhuma dificuldade, levem a sério, estejam dispostos a sacrificar um pouco de suas vidas pois no final verás que valeu a pena.

#LAB
Agendei o LAB para Setembro e consegui ficar em casa nas duas semanas antes da data agendada e segui as seguintes regras:
- Acordava as 6 am todos dos dias e as 7 am começa a brincar com o lab usando o material do INE e IPExpert.
- Acordava as 6 pois a prova é as 7 am, então tentei fazer meu corpo me acostumar o máximo possível ao seria no dia da prova.
- Agendei a prova em RTP pois o fuso horário é bem pequeno
- Cheguei 4 dias antes em RTP para me acostumar com tudo e tentar me sentir mais confortável ao ambiente.
- Mantive a rotina de acordar as 6 am e acessava meu lab remotamente e continuava praticando e sempre que dava eu dava uma volta pela cidade para tentar tirar um pouco a pressão do exame.
- Na noite anterior a prova tentei dormir cedo, 20h, mas não consegui pois estava muito ansioso e consegui dormir somente 1am :(

#DICA: Prepare o seu psicológico, tente manter o controle, caso algo esteja dando errado no lab passe para o próximo item, não desista, confie em si mesmo e se precisar levante e beba uma água para aliviar a pressão.

Eu fiquei tão nervoso por ser a minha primeira tentativa que eu não conseguia nem compreender a Task 1 onde precisamos somente configurar as vlans. Foi então que eu precisei me acalmar e organizar meus pensamentos e tudo fluiu como deveria.

Eu gostaria de agradecer toda minha família, amigos e colegas de trabalho que me ajudaram a concluir essa jornada. Obrigado pela paciência de todos e eu sei que nesse trajeto eu também deixei algumas pessoas de lado, mas somente quem sabia o quão importante era para mim esse objetivo se manteve ao meu lado, mesmo eu não podendo dar a atenção devida para cada um.

Eu não vou citar nomes pois foram muitas pessoas mesmo e eu não quero esquecer de ninguém, obrigado a TODOS!!!!

Henrique Moura
CCIE Collaboration #44884

################################################################################

Secure Conference Bridge

Nossa, agora me dei conta de como faz tempo que não escrevo aqui no blog! Desse jeito, como é que vou querer vender ele pra Cisco algum dia? hahaha! Enfim, escreverei hoje sobre um tema que me custou muito para fazer funcionar, simplesmente porque é extremamente difícil de encontrar boas referências sobre essa configuração na Internet: Conference Bridge com criptografia (usando a infraestrutura de certificados do cliente).

É um tema bastante similar ao que escrevi outro dia sobre SIP Trunk over TLS, só que criaremos outras chaves, outro trustpoint, etc. E novamente, reforçarei o que escrevi nesse post sobre Secure SIP: Isso definitivamente não é a minha área de especialidade, então certamente tem coisa que pode estar errada. O que mostro abaixo é como eu fiz e deu certo.

1. Crie um par de chaves (pública e privada) no Voice Gateway, dando um nome qualquer (diferente do nome que foi dado às chaves do Secure SIP). Sugiro o nome da própria Conference Bridge:

crypto key generate rsa general-keys label CFB_Teste_01 mod 2048 exportable

2. Crie um Trustpoint no Voice Gateway, e nomeie ele com o mesmo nome da Conference Bridge:

crypto pki trustpoint CFB_Teste_01
 enrollment terminal
 fqdn none
 subject-name CN=CFB_Teste_01  ! -- Aqui está o segredo. O CN do certificado deve conter o nome da Conference Bridge
 revocation-check none
 rsakeypair CFB_Teste_01

3. Autentique o trustpoint, incluindo certificado Root

crypto pki authenticate CFB_Teste_01

Ao dar o comando, o roteador vai pedir para você colar o certificado root. Esse certificado você deve pedir ao cliente:

Enter the base 64 encoded CA certificate
<COLE A STRING CONTENDO O CERTIFICADO ROOT>

4. Gere o CSR (Certificate Sign Request) do roteador para ser assinado pelo cliente:

crypto pki enroll CFB_Teste_01
%Start certificate enrolment ..
Include serial? No
Include IP Address? No
Display CSR? Yes

O roteador vai gerar uma string no terminal. Você deve copiar toda ela num TXT e encaminhar para o cliente assinar no CA dele. Caso seja um Windows, o template deve conter as funções TLS Web Server Authentication, TLS Web Client Authentication e IPSec End System.


5. Quando o cliente enviar o certificado assinado pelo CA dele, importe de volta para o Roteador:

crypto pki import CFB_Teste_01 certificate
Enter the base 64 encoded certificate
<COLE A STRING CONTENDO O CERTIFICADO ASSINADO>

6. Importe os certificados Root no CUCM como CallManager-trust, e assine os certificados do CUCM no CA do cliente. O passo-a-passo desse procedimento está detalhado no post sobre Secure SIP.

7. Crie uma nova Conference Bridge no roteador, como de costume, porém, seguindo os comando abaixo:

sccp local GigabitEthernet0/0
sccp ccm <CUCM1> identifier 1 version 7.0 trustpoint CFB_Teste_01
sccp ccm <CUCM2> identifier 2 version 7.0 trustpoint CFB_Teste_01
sccp ip precedence 3
sccp

sccp ccm group 1
 bind interface GigabitEthernet0/0
 associate ccm 2 priority 1
 associate ccm 1 priority 2
 associate profile 1 register CFB_Teste_01

dspfarm profile 1 conference security
 trustpoint CFB_Teste_01
 codec g729br8
 codec g729r8
 codec g729abr8
 codec g729ar8
 codec g711alaw
 codec g711ulaw
 maximum sessions 2
 associate application SCCP

8. Ao criar a CFB no Call Manager, marque a opção "Encrypted Conference Bridge".

Pronto, a sua Conference Bridge já está encriptada!

UCCX Scripting: Mandando um e-mail quando o cliente desiste de esperar na fila

Olá pessoal!

Hoje vou fazer mais um post sobre UCCX Scripting, que teve origem em uma demanda real de um cliente. Basicamente o que esse cliente queria era que quando alguém estivesse na sua fila do CCX e, cansado de esperar, desligasse a chamada, um e-mail fosse enviado para o supervisor do atendimento informando o número do cliente, para que a ligação pudesse ser retornada depois.

Hmmm, tricky, heim? Pensei eu com os meus botões... "como vou fazer o script continuar o fluxo quando o cliente encerra a chamada?"

Foi aí que, procurando referências na Internet, cheguei a um exception chamado ContactInactiveException. Esse Exception consegue capturar o fluxo justamente quando o cliente do outro lado da linha encerra a ligação. E com ele, desenvolvi esse script:

/* Variáveis */
String ani
String csqID = "Fila"
Prompt pEspera = P[espera.wav]
Contact Email

ani = Get Call Contact Info (Calling Number)
Select Resource (csqID)
  Queued
    On Exception (ContactInactiveException) Goto ABANDONED
    <LABEL: QUEUE>
    Play Prompt (pEspera)
    Goto QUEUE

<LABEL: ABANDONED>
Email = Create eMail("Chamada perdida de "+ani)
Send eMail(bnonogaki@ngk.com)

E o script no editor ficou assim:

Com isso, quando o cliente desligava a chamada durante a fila, um e-mail era enviado para bnonogaki@ngk.com com o conteúdo "Chamada perdida de <ANI>"

É claro que para isso funcionar, você precisa de ter o licenciamento Premium do CCX (que tem suporte a e-mail), configurar o SMTP no servidor, e permitir o SMTP Relay do CCX no Exchange.

Um scriptzinho simples, e bastante útil... você pode pegar o ANI e alimentar uma campanha de outbound dialer, por exemplo. Aliás, outbound dialer seria um belo tópico para um post futuro! :)

UCCX Scripting: Buscando usuarios no Corporate Directory

Esse é o primeiro post da série de CCX Scripting. Algumas coisas bacanas que podemos fazer com o CCX além de pegar uma chamada e encaminhar para uma fila. Esse post surgiu de uma necessidade real em um cliente, e achei a solução bastante interessante. Fica a dica para quem também estiver precisando.

Basicamente o cliente queria que quando uma chamada entrasse no Call Center, o sistema identificasse o nome da pessoa pelo ramal, e exibisse na tela do agente. O jeito que encontrei para fazer isso é buscar o ramal no Corporate Directory do CUCM, encontrando o nome do usuário. Obvio que a premissa para isso é que os End Users do CUCM estejam propriamente configurados com o ramal certo. Geralmente em implantações com o LDAP integrado, isso já vem certinho.

Segue a lógica de programação abaixo:

/* Variáveis */
Document xmlCorpDirectory
String dirURLCorpDir
String callingNumber
String callingName

Set dirURLCorpDir = "http://X.X.X.X:8080/ccmcip/xmldirectorylist.jsp?n="
callingNumber = Get Call Contact Info (Calling Number)

if ((callingNumber != null && callingNumber.trim() != "")) Then
   xmlCorpDirectory = Create XML Document(URL[dirURLCorpDir + callingNumber])
   callingName = Get XML Document Data (xmlCorpDirectory, "//Name")
   if ((callingName != null && callingName.trim() != "") Then
      /* Continue */
   else
      Set callingName = "Nao identificado"
else
   Set callingName = "Nao identificado"

E como ficou no CCX Editor:

Luciano Tamarozzi, CCIE #41857

Pessoal, abaixo um depoimento do Luciano Tamarozzi, que passou na prova no começo desse ano. Parabéns Luciano!!!

################################################################################

Primeiramente Bruno obrigado pela Oportunidade e Parabéns pelo Blog ele me ajudou muito nesta jornada.
Bom minha trajetória é semelhante a dos demais CCIEs, mas acho interessante compartilhar para que as pessoas que estão estudando tenham alguma referencia, no meu caso cada vez que via um depoimento aqui no Blog ficava mais animado e com vontade de passar.
Minha saga começou no inicio de 2012 quando comecei a montar um LAB em casa, optei por montar por que na época o único link de internet que chegava a minha casa era 3G assim não era possível usar LABs Alugados, levei até Outubro de 2012 para montar e comprei tudo pelo Ebay. Assim que terminei de montar o LAB resolvi comprar os materiais para começar estudar e junto com alguns amigos comprei os materiais do INE.
Assim que compramos o material já iniciei os estudos, a primeira fase de estudos é a hora de você aprender todas as tecnologias contidas Blueprint e nesta fase você não vai a fundo a cada item, por exemplo, você não precisa saber implementar Gatekeeper com todas as variações mas sim entender bem o conceito, esta fase durou 5 meses eu estudava cerca de 2 horas por dia durante a semana e 8 horas em cada dia de folga. 
Então em março fiz a prova escrita, pois já tinha conhecimento sobre todas as tecnologias da contidas na prova, em seguida já iniciei o Workbook 1 do INE nesta parte você aprende todas as variações de cada tecnologia você realmente vai a fundo em cada item e o importante era a precisão e não a velocidade, em paralelo ao Workbook 1 também estava lendo alguns documentos ( Admin Guides e algumas seções do SRND), acabei o workbook 1 em Julho nesta época já estava estudando 4 horas por dia durante a semana e 12 horas cada dia de folga definitivamente já não tinha mais vida Social.
No final de Julho agendei o LAB para final de novembro, comecei então Workbook 2 que são de MOC LABs usei tanto o INE quanto o IPExpert, optei pelos 2 para ser mais efetivo pois quando você faz o LAB varias vezes você acaba decorando e não é tão proveitoso. Durante a semana eu fazia 1 lab em 3 dias, os 2 primeiros eram as configurações e o terceiro era só para a correção, é muito mais efetivo quando você corrige sua prova com a cabeça fria sem o stress de ter feito um monte de configurações, você corrige a prova mais critico. Quem havia indicado esse método foi um amigo que já havia passado no LAB.
Em meados de Setembro já estava comendo tudo com farinha, porem não havia conseguido preparar uma das coisas mais importantes que é a estratégia, nessa época o Bruno lançou 2 posts interessantes sobre estratégia, com base nestes Posts e a Ajuda de outro amigo que estava Estudando consegui desenvolver minha própria estratégia e assim conseguia terminar os LABs em até 4 horas.
Chegando a época da prova peguei férias aonde trabalho e fiquei 100% dedicado ao LAB, então no final de Novembro fui para Sao Jose e fiz minha primeira tentativa, fui bem consegui terminar e testar tudo e sai de lá com a certeza de ter passado, porem quando vi o resultado que havia falhado foi uma surpresa e não sabia aonde poderia ter errado, voltando ao Brasil falei com alguns amigos e consegui entender onde errei porem desanimei, pois não havia mais vagas para fazer o LAB que mudava a versão em fevereiro. No começo de dezembro eu estava no Trem e o Peterson me ligou avisando que abriram algumas vagas em RTP, fui correndo para tentar agendar, mas como eu havia ficado a noite inteira logando para ver se havia vagas, meu login foi bloqueado e só ia liberar no dia seguinte, meus amigos ficaram monitorando as vagas e em cerca de 1 hora só sobrou uma, foi então que liguei para Cisco e pedi para eles agendarem para min depois de muita conversa eles decidiram agendar e marcaram para 05 de janeiro. 

Marcado a próxima tentativa a minha empresa me deu mais 15 dias de Férias o que me ajudou muito a pegar o Ritmo novamente. Chegou a hora do LAB e foram difíceis os primeiros 30 minutos, pois minha mão estava congelada, após isso as configurações renderam bem e consegui terminar o LAB antes do almoço (RTP foi 5 horas antes do almoço), depois foi só corrigir e checar alguns detalhes com o Proctor. Sai de lá com medo, pois na tentativa anterior também havia terminado e testado, ai para aliviar fui à casa de um amigo que mora lá e fizemos um churrasco depois cheguei ao hotel e fui dormir acordei então as 3 da manhã com um e-mail da Cisco informando que o resultado do LAB já estava disponível e para minha alegria havia passado. Não tem palavras para descrever a alegria de ter passado!

O conselho que dou para quem vai tentar é que se prepare tanto Psicologicamente e Financeiramente, como o Bruno disse antes é bom ter dinheiro para 2 ou 3 tentativas se passar antes é lucro. Não estude sozinho procure pessoas que estão estudando para compartilhar experiências, isso me ajudou muito. E não desanime quando falhar, mas sim aprenda com o erro.

Agora estou na torcida dos amigos que irão prestar a prova nos próximos dias e provavelmente teremos mais CCIEs Voice no Brasil.

Gostaria de Agradecer aos Amigos: Sergio Polizer, Peterson, Alan, Fernando Cesar e Emanuel Damasceno. Todos me ajudaram nesta Jornada!

################################################################################

Criptografando o seu SIP Trunk com TLS

Fala pessoal!!!
Primeiramente, gostaria de desejar um feliz 2014!!

Faz bastante tempo que eu num faço um post no blog que não seja relatos de pessoas que passaram na prova. Confesso que é uma forma bastante prática de manter o blog atualizado! hahaha... só que num é só disso que pode viver o blog, né? Por outro lado, o blueprint atual está quase no fim, e não tenho o intuito de ficar me atualizando no blueprint novo para postar coisas relativas à próxima prova (a não ser que eu capitalize o blog e comece a ganhar dinheiro com isso! hahaha).

Portanto, hoje farei um post sobre um assunto que num tem nada a ver com a prova (pelo menos não a atual), mas que eu achei extremamente difícil achar referências boas na Internet quando precisei fazer. É sobre a configuração de um voice gateway SIP criptografado (TLS), usando certificados da estrutura do cliente. O que tem bastante na internet é sobre como fazer usando certificados self-signed do CUCM e Gateway, mas convenhamos que num deployment real, dificilmente isso vai acontecer. Geralmente o cliente tem toda uma estrutura de certificados da empresa para os seus serviços, e pede que a gente utilize essa estrutura.

Ok, serei sincero. Isso definitivamente não é a minha área de especialidade, então certamente tem coisa que pode estar errada. O que mostro abaixo é como eu fiz e deu certo.

Importando os certificados no Roteador

1. Crie um par de chaves (pública e privada) no Voice Gateway, dando um nome qualquer. Sugiro nomear com o próprio Hostname do roteador:

crypto key generate rsa general-keys label <HOSTNAME> mod 2048 exportable

2. Crie um Trustpoint no Voice Gateway, e nomeie ele com o Hostname:

crypto pki trustpoint <HOSTNAME>
 enrollment terminal
 fqdn HOSTNAME.domain.example.com ! - hostname e domínio
 subject-name CN=HOSTNAME.domain.example.com
 revocation-check none
 rsakeypair <HOSTNAME> ! - referencia às chaves criadas  no passo 1

3. Autentique o trustpoint, incluindo certificado Root

crypto pki authenticate <HOSTNAME>

Ao dar o comando, o roteador vai pedir para você colar o certificado root. Esse certificado você deve pedir ao cliente:

Enter the base 64 encoded CA certificate
<COLE A STRING CONTENDO O CERTIFICADO ROOT>

4. Gere o CSR (Certificate Sign Request) do roteador para ser assinado pelo cliente:

crypto pki enroll <HOSTNAME>
%Start certificate enrolment ..
Include serial? No
Include IP Address? No
Display CSR? Yes

O roteador vai gerar uma string, que você deve copiar toda ela num TXT e encaminhar para o cliente assinar no CA dele. Caso seja um Windows, o template deve conter as funções TLS Web Server Authentication, TLS Web Client Authentication e IPSec End System.


5. Quando o cliente enviar o certificado assinado pelo CA dele, importe de volta para o Roteador:

crypto pki import <HOSTNAME> certificate
Enter the base 64 encoded certificate
<COLE A STRING CONTENDO O CERTIFICADO ASSINADO>

Agora vamos fazer a parte dos certificados do CUCM.

Importando os certificados no CUCM

1. No CUCM, entre no OS Administrator. Vá em Security >> Certificate Management

2. Clique em Upload Certificate, e faça upload do Certificado Root para CallManager-trust e tomcat-trust.

3. Clique em Generate CSR e gere os CSRs do CallManager e tomcat.

4. Clique em Download CSR para baixar os arquivos

5. Envie para o cliente assinar no CA dele. Caso seja um Windows, o template deve conter as funções TLS Web Server Authentication, TLS Web Client Authentication e IPSec End System.

6. Quando o cliente mandar os certificados assinados, importe novamente como CallManager e tomcat (sem o trust).

7. Faça isso em todos os servidores do cluster, e depois reinicie tudo.

Configurando o SIP Trunk no CUCM

1. Crie um SIP Trunk Security Profile, marcando a opção Encrypted, com transport type TLS. No X.509 Subject Name, coloque o Hostname e Domain name do roteador, como no exemplo abaixo

2. Crie um SIP Trunk como o usual, mas marque a opção SRTP Allowed, aplique o Security Profile criado acima, e utilize a porta 5061 como Destination Port. Como Device Name do trunk, utilize o Hostname do roteador.

Configurando o SIP Trunk no Gateway

1. Crie a dial-peer voip normalmente, porém com os dois comandos destacados abaixo:

dial-peer voice X voip
 destination-pattern <XXXX>
 session protocol sipv2
 session target ipv4:x.x.x.x:5061
 session transport tcp tls
 srtp fallback
 (...)

2. Configure o SIP-TLS:

sip-ua
 crypto signalling remote-addr <CUCM-Pub> 255.255.255.255 trustpoint <HOSTNAME> strict-cipher
 crypto signalling remote-addr <CUCM-Sub> 255.255.255.255 trustpoint <HOSTNAME> strict-cipher

E pronto!

Troubleshooting

Esses debugs são muito úteis para fazer o troubleshooting do TLS

debug ssl openssl errors
debug ssl openssl msg
debug ssl openssl state
show sip-ua connection tcp tls detail