domingo, 20 de maio de 2012

Unity Connection - Integrações com o CUCM

Na parte de Messaging da prova, o blueprint aborda dois produtos: Cisco Unity Connection e Cisco Unity Express. Com eles, existem 6 formas possíveis de integração a serem testadas:
1. Unity Connection + Call Manager usando SCCP
2. Unity Connection + Call Manager usando SIP
3. Unity Connection + Call Manager Express usando SCCP
4. Unity Connection + Call Manager Express usando SIP
5. Unity Express + Call Manager usando JTAPI
6. Unity Express + Call Manager Express usando SIP

Hoje eu vou falar sobre as duas primeiras, que envolvem o Unity Connection com Call Manager.

1. Unity Connection + Call Manager usando SCCP

Essa é a integração que a gente mais faz no dia-a-dia. É bem provável inclusive que ela já venha pronta na prova, e você só tenha que fazer um troubleshooting para descobrir o que tem de errado. De qualquer forma, é bom saber bem como se faz essa integração, porque pode te garantir uns pontinhos de graça na prova.
Vamos começar pela parte do Call Manager. Basicamente aqui a gente vai ter que criar as VM Ports e colocá-las num Line Group. Associamos o Line Group a uma Hunt List e a Hunt List a um Hunt Pilot. Depois criamos os MWI, o Voice Mail Pilot e o Voice Mail Profile! Parece que é um monte de coisa, mas dá para fazermos tudo em menos de 5 minutos.

1.1. Voice Mail Port Wizard
O Wizard (Voice Mail >> Cisco Voice Mail Port Wizard) é guia para a criação das VM Ports. Com ele, podemos criar todas as portas de uma vez e associá-las a um Line Group automaticamente. Os passos desse Wizard são:
a. Escolher se você quer criar uma nova integração, adionar portas a uma integração já existente ou deletar portas. No caso, vamos criar uma nova integração.
b. Escolher um nome para as portas. Esse nome tem que bater com o que você vai configurar depois na Unity Connection, então anote o que você colocar. Recomendo usar o default: CiscoUM1.
c. Informar o número de portas que será criado. Isso vai depender da sua licença, se for na vida real, ou do enunciado da questão, se for na prova. O número de portas define a quantidade de acessos simultâneos que a Unity Connection vai suportar.
d. Configurar a porta. As informações principais que você deve se atentar são: Device Pool, Calling Search Space, AAR CSS e Location.
e. Configurar os DNs. As informações principais que você deve se atentar são: Beginning Directory Number, Partition, Calling Search Space, AAR Group e External Phone Number Mask (em caso de cair AAR na prova, não esqueça de preencher isso aqui!). O Beginning DN vai definir qual será o seu range de ramal para as VM Ports, baseado na quantidade de portas que você definiu lá em cima... ele vai alocar os ramais sequencialmente a partir desse beginning directory number.
f. Configurar o Line Group. Aqui ele vai perguntar se você quer criar um novo line group, adicionar as portas a um line group já existente ou criar o line group manualmente depois. Vamos criar um novo Line Group.
g. Dar um nome para o Line Group. Qualquer nome...
h. Confirmar as informações que serão adicionadas. Se clicar em Next, ele já vai aplicar as alterações.
i. Resumo do que foi criado.

1.2. Line Group, Hunt List e Hunt Pilot
Agora que você já tem um Line Group criado com as suas VM Ports dentro, vamos associá-lo a uma Hunt List, que por sua vez será associada a um Hunt Pilot:
a. Call Routing >> Route/Hunt >> Hunt List: Crie uma nova Hunt List e associe o Line Group criado no Wizard. Marque a opção "For Voice Mail Usage".
b. Call Routing >> Route/Hunt >> Hunt Pilot: Crie um novo Hunt Pilot e associe o Hunt List criado acima. O Hunt Pilot será o número de acesso ao Voice Mail. Denovo, se você for ter que configurar AAR, não esqueça de colocar o AAR Group e External Phone Number Mask!

1.3. MWI, VM Pilot e VM Profile
O resto da integração, teremos que seguir manualmente, sem um Wizard. Mas é pouca coisa:
a. Voice Mail >> Message Waiting Numbers: Aqui definiremos o MWI, que é o alerta no telefone indicando que há uma nova mensagem no correio de voz. Será um ramal para On (ligar o alerta) e um ramal para Off (desligar o alerta) que a Unity Connection utilizará para acender e apagar a luzinha nos telefones.
Adicione os dois ramais e guarde esses números, pois precisaremos deles mais tarde. Atenção: O MWI também tem Partition e CSS. Os ramais devem ter acesso a ele, e ele deve ter acesso aos ramais. Se você tiver configuração de IPMA, a CSS do MWI deve ter acesso ao ramal do chefe!

b. Voice Mail >> Voice Mail Pilot: Colocamos aqui o VM Pilot (que tem que ser o mesmo número do Hunt Pilot criado acima). Basicamente, ele é um "Speed Dial" para o Hunt Pilot para quando você pressionar o botão Messages do telefone.
c. Voice Mail >> Voice Mail Profile: No Voice Mail Profile amarramos o Voice Mail Pilot e colocamos (ou não) uma máscara.
Digamos que você tenha 2 sites pendurados nesse cluster: Site A e Site B. O Site A usa um Unity Connection com o VM Pilot 5000 e o Site B usa um Unity Express com o VM Pilot 2000. Quando um telefone do Site A pressionar a tecla Messages, ele tem que ser mandado para o seu Voice Mail na Unity Connection, enquanto o usuário do Site B, quando pressionar o mesmo botão no seu telefone, tem que ser mandado para o seu Voice Mail na Unity Express. Para essa situação, teríamos que criar dois Profiles diferentes, um para cada site, e cada profile teria associado o VM Pilot correspondente.
Outra finalidade do VM Profile é a seguinte: Imagine que o seu ramal no CUCM é 5001. Mas por algum motivo, o seu ramal na Unity Connection teve que ser criado no formato 5511XXXX (tipo 55115001)... talvez por um problema de ramais duplicados, sei lá. Mas nesse caso, como o seu ramal no CUCM é diferente do seu ramal na Unity, teriamos que colocar uma máscara no Voice Mail Profile: 5511XXXX. Assim, quando você fosse acessar o Voice Mail, o CUCM enviaria para a Unity os digitos 55115001 e não 5001.

1.4. Ramais e Usuários
Só precisamos fazer mais duas coisas no CUCM:
a. Nos ramais que terão Voice Mail, marque o desvio para o Voice Mail nos casos de busy e no answer... e talvez no unregistered também, dependendo do que for pedido na prova.
b. Crie um End User para cada usuário, associe o Device (ou Device Profile em caso de Extension Mobility), e preencha o campo Primary Extension. Sem ele preenchido, a Unity não vai enxergar esse usuário na hora da importação.

1.5. Unity Connection: Phone System
Finalmente vamos para a Unity Connection:
a. Telephony Integration >> Phone System: Utilize o Phone System default já existente.
b. Vá em Edit >> Cisco Unified Communications Manager AXL Servers: Coloque os IPs dos CUCMs, e porta 443 (SSL). Cuidado para não deixar a porta 0, que é a default. Coloque o usuário e senha de admin do Call Manager (ou algum outro que tenha permissão de AXL).
c. Volte na tela inicial do seu Phone System, e clique em Add Port Group, em Related Links, no canto superior direito da tela.

1.6. Unity Connection: Port Group
a. Dê um nome para o seu Port Group (default: PhoneSystem-1)
b. Em Device Name Prefix, você vai colocar o mesmo que definiu lá em cima no Wizard. Mas atenção, o nome tem que ter um "-VI" na frente... maluquisses da Cisco. Então, como o nome que definimos foi CiscoUM1, o Device Name Prefix vai ser CiscoUM1-VI. Isso é clássico de cair na prova para resolver problema de integração...
c. Preencha os MWI Extensions de acordo com o que você configurou antes.
d. Coloque o IP do CUCM.
e. Volte na tela inicial do Port Group, e vá em Edit >> Servers. Preencha os dados do seu CUCM.
f. Volte na tela inicial do Port Group, e clique em Add Ports, no canto superior direito.

1.7. Unity Connection: Ports
Ta acabando... aqui apenas defina a quantidade de portas, de acordo com o que você colocou no Wizard. E pronto! Você deve conseguir já ver as suas Voice Mail Ports registradas no CUCM. Se não tiverem registrando, um bom passo para começar o troubleshooting é ir em Phone System, e depois em Check Telephony Configuration em Related Links, no canto superior direito.


1.8. Unity Connection: Import Users
Agora é só ir em Tools >> Import Users, e importar os usuários criados no CUCM. Talvez antes disso você queira mudar o seu User Template, definir um PIN inicial e tudo mais.


2. Unity Connection + Call Manager usando SIP
Muito mais rápido!!!

a. No CUCM, crie um SIP Trunk Security Profile: System >> Security Profile >> SIP Trunk Security Profile. Esse profile deve ter marcado Accept Replaces Header, Accept Out-of-Dialog REFER, Accept Unsolicited Notification.
b. Crie um SIP Trunk para a Unity Connection, usando esse profile acima. No SIP Trunk, marque a opção Redirecting Diversion Header Delivery - Outbound
c. Crie uma Route Pattern apontando para o SIP Trunk. Essa Route Pattern será o seu Voice Mail Pilot.
d. Em Voice Mail Pilot, coloque o número que você configurou na Route Pattern.
e. Na Unity Connection, vá em Telephony Integrations >> PhoneSystem e configure do mesmo jeito que fizemos antes. Depois clique em Add Port Group.
f. No Port Group, selecione SIP no Port Group Template. E em IP Address or Hostname, coloque o IP do CUCM. Em Edit >> Servers, coloque as informações do seu CUCM também.
g. Clique em Add Ports, e coloque o número de portas que você quer configurar.
h. E só! Não precisa de Wizard nenhum, nem Voice Mail Ports, nem MWI Extensions, nada disso!


3. Configurando o botão Messages do telefone
Pelos labs da IP Expert, vi que eventualmente podem ter apagado o serviço do botão de Messages do seu telefone, e você tem que saber recriá-lo. Sem esse serviço, quando você aperta o botão de Messages não acontece nada. Uma puta falta de sacanagem cair isso na prova...
Bom, para recriar, ou você faz na mão (em Device >> Device Settings >> Phone Services), ou você faz via linha de comando por uma query SQL. Se for fazer na mão, tem que lembrar que a URL é Application:Cisco/Voicemail, o Service Type é Messages, e a categoria é XML. E marque Enterprise Subscriptions também. 
Caso não queria lembrar de tudo isso, é só entrar no Release Notes da versão 7.0(1) do CUCM (que você terá acesso na prova) e dar um search por "Voicemail". Lá tem uma query para ser executada via console:
run sql insert into telecasterservice (pkid,Name,NameASCII,Description,URLTemplate,tkPhoneService,EnterpriseSubscription,Priority) values('ca69f2e4-d088-47f8-acb2-ceea6722272e','Voicemail','Voicemail','Voicemail','Application:Cisco/Voicemail',2,'t',1)  
Aplique isso, dê um boot nos phones e já era.

terça-feira, 15 de maio de 2012

CME Class of Restrictions

Um assunto que sempre me deu um pouco de nó na cabeça é a restrição de chamadas no CME. No CUCM estamos mais acostumados (pelo menos eu). Criamos as partitions e atribuímos às rotas para bloqueá-las; criamos as Calling Search Spaces e atribuimos aos devices para dar permissão.
Agora chega no CME e é "totalmente" diferente... tem as cor customs, cor lists, aplicamos como incoming em alguns lugares, outgoing em outros... uma zona! As explicações nas documentações da Cisco dizem que um ramal vai conseguir acesso a uma dial-peer caso o corlist do ramal seja um superconjunto (lembram disso?) da corlist da dial-peer. Não muito didático, né?

Bom, mas se pararmos para analisar, no CUCM também o ramal só vai conseguir ver uma pattern caso a sua Calling Search Space contenha a partition da rota. Ou seja, a CSS é um superconjunto do conjunto de partitions atribuídos a uma pattern. A diferença é o conjunto de partitions atribuído a uma pattern é formado por uma única partition. O que podemos concluir disso é que uma analogia entre Partitions/CSS do CUCM com Cor Lists do CME é totalmente plausível.

No CME, aplicamos os cor lists nas dial-peers (lembrando que quando criamos um ephone-dn, na realidade estamos criando uma dial-peer virtual para aquele ramal). E as cor lists possuem direção: incoming e outgoing. É só se colocar no lugar do roteador... quando a chamada vem de um ramal, ela é incoming. E quando sai para uma rota, ela é outgoing. Então geralmente aplicamos como incoming no ephone-dn (dial-peer de entrada) e como outgoing na pots dial-peer de saída.
No lado incoming, é o ephone-dn querendo fazer uma chamada. Então podemos considerar a cor list incoming como uma Calling Search Space.
E no lado outgoing, é a rota se bloqueando ou não para um ramal. Então podemos considerar a cor list outgoing como uma Partition.
Pronto, montamos a nossa analogia com o CUCM.
Obs: Essa não é a analogia/explicação que a Cisco usa nas documentações! Essa aqui é um pouco diferente e eu bolei de forma que eu pudesse lembrar melhor... se você nunca viu isso antes, sugiro ler as documentações da Cisco antes para ver como eles tratam oficialmente o assunto.

Bom, vamos ver um exemplo:

Digamos que tenho dois ramais criados no CME: ephone-dn 1 e ephone-dn 2. O 1 vai ter acesso a chamadas locais, e o 2 vai ter acesso a chamadas locais, DDD e DDI. Como podemos fazer isso?

1. Declarando a cor custom
Primeiramente precisamos declarar a nossa lista de cor custom. A Cisco faz uma analogia dessa lista com as Partitions, mas eu prefiro não encarar elas dessa forma. Basicamente aqui vamos definir algumas nomenclaturas para identificar cada tipo de chamada que queremos bloquear ou liberar. No caso, local, DDD e DDI.
dial-peer cor custom
 name local
 name DDD
 name DDI

2. Criando a cor list de saída
Agora vamos criar as cor lists. Vou separar em duas etapas: as cor list de entrada e as cor list de saída. Mas em termos de comando, é a mesma coisa. Vou separar apenas para ficar mais fácil de entender. As nossas cor lists de saída funcionarão como Partitions, pois elas que vão bloquear ou liberar a rota para um ramal.
dial-peer cor list PT-Local
 member local

dial-peer cor list PT-DDD
 member DDD

dial-peer cor list PT-DDI
 member DDI

Dentro de uma cor list, eu posso colocar vários members, como veremos adiante. Porém, para as cor list de saída, vamos deixar 1 member só. Lembra que eu falei que no CUCM "o conjunto de partitions atribuído uma pattern é formado por uma única partition". Então, é a mesma coisa... o conjunto de members atribuído a uma cor list de saída é formado por um único member.

3. Criando a cor list de entrada
E agora vamos criar as cor list de entrada, que serão as nossas "Calling Search Spaces". No CUCM a CSS só vê a rota quando a partition da rota estiver dentro da CSS, certo? Aqui é a mesma coisa. A cor list de entrada só vai ver a cor list de saída quando o member da cor list de saída estiver dentro da cor list de entrada. Portanto:

dial-peer cor list CSS-Local
 member local

dial-peer cor list CSS-DDD
 member local
 member DDD

dial-peer cor list CSS-DDI
 member local
 member DDD
 member DDI

Veja que por enquanto apenas criamos as cor lists. Não há nada ainda diferenciando elas entre uma cor list de entrada e uma cor list de saída, exceto pela nomenclatura.

4. Aplicando na dial-peer de saída
Agora que temos tudo criado, vamos aplicar nas dial-peers. Primeiramente nas de saída.
O que faremos a seguir será como se estivéssemos atribuindo uma Partition a uma rota, como no CUCM.

dial-peer voice 1 pots
 description *** Chamadas de Emergencia ***
 destination-pattern 019.
 port 0/0/0:15
 forward-digits 3

dial-peer voice 10 pots
 description *** Chamadas Locais ***
 destination-pattern 0[2-9].......
 port 0/0/0:15
 corlist outgoing PT-Local

dial-peer voice 11 pots
 description *** Chamadas DDD ***
 destination-pattern 0[0][^0][^0][^0][^0][2-9].......
 port 0/0/0:15
 corlist outgoing PT-DDD

dial-peer voice 12 pots
 description *** Chamadas DDI ***
 destination-pattern 0[0][0]T
 port 0/0/0:15
 corlist outgoing PT-DDI

Repare que a dial-peer de chamadas de emergência não possui corlist. Logo, ela não é bloqueada.

4. Aplicando na dial-peer de entrada
Agora vamos aplicar nas dial-peers de entrada. No caso, nos ephones-dn.
O que faremos a seguir será como se estivéssemos atribuindo uma Calling Search Space a um ramal.

ephone-dn 1 dual-line
 number 1000
 corlist incoming CSS-Local

ephone-dn 2 dual-line
 number 1001
 corlist incoming CSS-DDI

ephone-dn 3 dual-line
 number 1002

E agora esse ephone-dn 3 que num tem nenhuma corlist associada? Pois é... isso é diferente do CUCM. Quando não há nenhuma corlist na dial-peer de entrada, ela por padrão tem tudo liberado. Logo, esse phone conseguiria fazer Local, DDD e DDI! Para bloquear esse ramal, poderíamos criar uma  cor list de entrada vazia e aplicar ao ephone:
dial-peer cor list CSS-Block

ephone-dn 3
 corlist incoming CSS-Block

Outro exemplo
E se quisermos fazer o ephone-dn 4 não conseguir ligar internamente para o ephone-dn 5? Aí poderiamos fazer assim:

dial-peer cor custom
 name ephone5

dial-peer cor list PT-Ephone5
 member ephone5

dial-peer cor list CSS-Ephone4

ephone-dn 4 dual-line
 number 1004
 corlist incoming CSS-Ephone4

ephone-dn 5 dual-line
 number 1005
 corlist outgoing PT-Ephone5

Ou seja, em algumas situações, a sua dial-peer de saída pode não ser uma pots para a PSTN. Assim como a sua dial-peer de entrada não precisa ser sempre um ephone-dn. Tudo vai depender dos seus requisitos.
Denovo, para saber quando é incoming e quando é outgoing, coloque-se sempre no lugar do roteador. No exemplo acima era uma chamada vinda do ephone-dn 4 para o ephone-dn 5. Logo, o 4 é incoming e o 5 é outgoing.

segunda-feira, 14 de maio de 2012

Primeiro lab remoto

Nesse final de semana fiz os meus primeiros labs remotos da ProctorLabs (Lab1, Volume 2 do IPExpert). E achei interessante compartilhar aqui o resultado. Como toda "primeira vez", estava meio atrapalhado... fui bem mal no sábado, não consegui terminar toda a prova e fiquei meio perdido algumas horas. Despesperante! Eu li o lab, sabia mais ou menos o que tinha que fazer, mas não consegui organizar os meus pensamentos de forma a bolar uma estratégia para atacá-lo.
Todo mundo fala que tem que ser rápido, não pode perder tempo e bla bla bla, então eu tentei fazer tudo o mais rápido que pude. Tipo, vou configurar um telefone no CUCM? Então já buscava na prova todos os requisitos para configurar o telefone de forma que eu tivesse que entrar na tela de config dele apenas uma vez! Então eu ía alternando entre as questões, tentando otimizar o meu tempo, e no final me perdi todo, não sabia direito o que tinha feito, o que faltava... foi um lixo.
Aí pensei... "não é possível... não pode ser assim que as pessoas otimizam o tempo! A não ser que você consiga organizar o seu raciocínio de uma maneira completamente foda".

Resolvi ver alguns comentários na Internet, mais especificamente esse post aqui do Vik Malhi: http://blog.ipexpert.com/2011/01/03/the-big-day-hour-1/

Recomendo fortemente a leitura! Com uma frase ele me entender o meu erro... "Walk before you can run". É isso! Não adianta você começar a prova já pensando como o Phone 1 do HQ vai apresentar o ANI em uma chamada de emergência, se você nem tem ainda o seu Phone 1 registrado! O importante é manter a calma, e se organizar. Se tiver que voltar na config do telefone para mudar uma CSS, tudo bem! Você num vai perder mais do que 15 segundos nisso... Percebi que não adianta economizar tempo com coisas idiotas como essas. Claro, tem coisa que é mais simples, então da pra ganhar uns minutinhos... tipo, configuração dos Softkeys templates, Phone Button templates, Service Parameters... isso só de vc ler a prova uma vez já da pra ter uma idéia do que você vai precisar alterar. Então faça uma vez só. Mas coisas mais complexas, principalmente as que envolvem Dial Plan, eu iria com mais calma.

Bom, o resultado do segundo lab (que eu acabei de acabar) foi bem melhor. Fiz novamente o Lab 1 (que acredito que seja mais facinho que os outros mesmo), e consegui acabar em 5h30. E ainda sobrou umas 2h pra revisar tudo e 15 minutos pra tomar banho! hauhauhau
Isso num lab real estaria ótimo! Claro, fazendo pela segunda vez eu já estava bem mais familiarizado com ele e tudo mais, mas mesmo assim fiquei satisfeito com o progresso.
Ao contrário da minha primeira tentativa, fiz a prova com mais calma e adotando a estratégia "technology-based approach", isto é, resolvendo as questões separando por assuntos (call routing, qos, high availability, ...). Acho que é bem mais fácil de você não se perder com essa estratégia. Tem gente que prefere o método device-based (http://www.youtube.com/watch?v=c1OKIJDDcaE), que é realmente bem interessante, só que acho que é muito fácil para você acabar se perdendo.

Comecei a prova da seguinte forma:
1. Infraestrutura e registro de devices: Faça isso o mais rápido que puder, porque é a parte mais fácil da prova
2. QoS: Acho melhor fazer no começo, porque se você zoar a sua WAN no final da prova, já era!
3. Call Routing: Depois de terminar Call Routing, você tira um peso das costas, e o resto flui mais fácil.


É isso aí, conforme eu for fazendo mais labs, vou colocando aqui o que aprendo com eles com relação a estratégia. Às vezes é a estratégia que define o seu sucesso ou fracasso.

E pra fechar o post, uma fotinha do meu home-lab, agora com telefones coloridos! hehehe
E feliz dia das mães! Graças à minha que estou aqui atrás desse desafio... quem diria, há 10 anos a minha mãe me incentivava a fazer o curso da Net Academy e hoje estou aqui estudando para um CCIE. Mãe sabe o que faz mesmo... hehehe


Ah, ontem lendo outros blogs, vi esse aqui do Matthew Berry (o cara do device-based approach):
http://ciscovoiceguru.com/548/ccie-voice-lab-strategy/
Ele diz: "make a commitment to keep an online blog"! uhu, acho que estou no caminho certo! hauhauhauhua...


sexta-feira, 11 de maio de 2012

WAN QoS (Frame Relay) - AutoQoS

Estava devendo esse post já há uns meses. No post que fiz em Janeiro sobre WAN QoS, abordei o MQC-Based, onde colocávamos o Traffic Shapping dentro de uma Policy-Map que era chamada pelo map-class frame-relay e etc, etc, etc. Na verdade, você só vai precisar configurar aquela forma de QoS se no enunciado ele for claro quanto a isso, ou se ele disser que você não pode usar o AutoQoS. Caso contrário, o jeito mais fácil e rápido de configurar o QoS na WAN é usando o nosso bom e velho amigo AutoQoS.


Então vamos para a primeira regra. SEMPRE antes de configurar qualquer coisa do seu auto qos, defina a banda do link na sua interface física. É baseado nesse valor que ele vai definir os seus parâmetros do Frame-Relay e do Traffic Shapping. Se você não colocar nada, ele vai considerar que a sua banda é de 1544Kbps, e aí ele não vai configurar o Traffic Shapping, pois ele só configura para links menores que 768Kbps.
Uma vez definida a banda na interface, entre na configuração do seu dlci e aplique um dos comandos abaixo:

auto qos voip trust
auto qos voip trust fr-atm
auto qos voip
auto qos voip fr-atm

Quatro comandos? Sim, quatro tipos de AutoQoS, e temos que saber bem a diferença entre eles... Mas é bem fácil! Os comandos com fr-atm configuram o AutoQoS usando MLPPP e os comandos sem o fr-atm configuram usando o FRF.12. Basicamente são duas formas de se configurar o LFI (Link Fragmentation and Interleaving). Então se o enunciado pedir MLP, coloque o fr-atm. Se pedir FRF.12, não coloque o fr-atm. Simples assim... Eventualmente no mesmo enunciado ele pode pedir para você configurar o link HQ - BR1 com MLP e HQ - BR2 com FRF.12... isso é perfeitamente possível. Em uma interface você configura com o fr-atm e na outra não. Bom, e o trust tá na cara, né? Com o trust ele vai confiar na marcação, e as suas class-maps vão dar match apenas no DSCP. Sem o trust ele não vai confiar na marcação vinda do Switch, e as suas class-maps vão reclassificar os pacotes novamente através de access-lists.

Vamos ver um pouco de configuração... fica mais fácil explicar:


Aplicando o AutoQoS
interface Serial0/0.1 point-to-point
 bandwidth 384                     ! -- Primeiro definimos a banda
 frame-relay interface-dlci 101    ! -- Depois aplicamos um dos
  auto qos voip trust              ! -- comandos de AutoQoS


Com o trust ou sem o trust?
Se você aplicar o trust no seu comando de auto qos, independente de usar ou não o fr-atm, a sua class-map ficará assim:
class-map match-any AutoQoS-VoIP-RTP-Trust
 match ip dscp ef
class-map match-any AutoQoS-VoIP-Control-Trust
 match ip dscp cs3
 match ip dscp af31
Repare que ele apenas deu match no DSCP e boa.

Se você não aplicar o trust, fica assim:
class-map match-any AutoQoS-VoIP-Remark ! -- Pode ignorar essa
 match ip dscp ef
 match ip dscp cs3
 match ip dscp af31
class-map match-any AutoQoS-VoIP-Control-UnTrust
 match access-group name AutoQoS-VoIP-Control
class-map match-any AutoQoS-VoIP-RTP-UnTrust
 match protocol rtp audio
 match access-group name AutoQoS-VoIP-RTCP

ip access-list extended AutoQoS-VoIP-Control
 permit tcp any any eq 1720
 permit tcp any any range 11000 11999
 permit udp any any eq 2427
 permit tcp any any eq 2428
 permit tcp any any range 2000 2002
 permit udp any any eq 1719
 permit udp any any eq 5060
ip access-list extended AutoQoS-VoIP-RTCP
 permit udp any any range 16384 32767
Repare que agora ele criou umas access lists para classificar o tráfego de RTP e Sinalização. Eventualmente o enunciado pode pedir para você não usar Access Lists. Nesse caso seria só remover tudo isso e configurar as class-maps com NBAR (match protocol XXX).


MLP 
Para os exemplos, vou considerar links menores que 768Kbps. Porque se for maior que isso, tanto faz porque o roteador não vai configurar LFI.
Quando configuramos MLPPP, o roteador cria uma interface virtual chamada Vitual-Template. Se o enunciado pedir para configurar MLP, nem pense em criar isso na mão porque vai dar um trabalhão!!! Deixe que o AutoQoS faça tudo por você. Detalhe que geralmente é necessário um reboot no router depois de aplicar essa config, senão você perde acesso a tudo... um bom motivo para nunca deixar QoS para o final da prova, porque se você quebrar a WAN nos 47 do segundo tempo, meu amigo...
Bom, a configuração usando MLPPP vai ficar assim:

policy-map AutoQoS-Policy-Trust
 class AutoQoS-VoIP-RTP-Trust
  priority percent 70        ! -- Essa é a sua LLQ, que provavel-
                             ! mente você tenha que modificar
                             ! depois. --
  compression header ip rtp  ! cRTP. Eu que adicionei essa linha
                             ! Por padrão o AutoQoS não habilita
                             ! o Class-Based cRTP. Se a prova 
                             ! pedir, é assim que faz. --
 class AutoQoS-VoIP-Control-Trust
  bandwidth percent 5
 class class-default
  fair-queue
interface Serial0/0.1 point-to-point
 description Connection to BranchOffice1
 bandwidth 384
 snmp trap link-status
 frame-relay interface-dlci 101 ppp Virtual-Template200
  class AutoQoS-FR-Se0/0-101
  auto qos voip trust fr-atm

interface Virtual-Template200  ! -- O AutoQoS que configurou isso
 bandwidth 384
 ip address 10.10.10.1 255.255.255.252
 ppp multilink
 ppp multilink interleave
 ppp multilink fragment delay 10
 service-policy output AutoQoS-Policy-Trust

map-class frame-relay AutoQoS-FR-Se0/0-101
 frame-relay cir 384000     ! -- Aqui um detalhe. O SRND diz que
 frame-relay bc 3840        ! esses valores devem ser 95% do CIR. 
 frame-relay be 0           ! ou seja, no caso, 36480. Então  
 frame-relay mincir 384000  ! teriamos que alterá-los na mão.
                            ! Mas se a prova não disser nada, deixe
                            ! assim ou confirme com o Proctor. --

FRF.12
Configuração de FRF.12 é bem mais tranquila. Da até para fazer na mão, se quiser. Tipo, você configura o HQ com auto qos, copia as configurações modificadas e cola na outra ponta da sua WAN. É uma boa tática para economizar um pouco de tempo.

policy-map AutoQoS-Policy-Trust ! -- Mesma coisa que lá em cima
 class AutoQoS-VoIP-RTP-Trust
  priority percent 70
 class AutoQoS-VoIP-Control-Trust
  bandwidth percent 5
 class class-default
  fair-queue

interface Serial0/0.1 point-to-point
 description Connection to HQ
 bandwidth 384
 ip address 10.10.10.6 255.255.255.252
 snmp trap link-status
 frame-relay interface-dlci 203
  class AutoQoS-FR-Se0/0-203
  auto qos voip trust
 frame-relay ip rtp header-compression ! -- Remova isso se for 
                                       ! usar  class-based cRTP --

map-class frame-relay AutoQoS-FR-Se0/0-203
 frame-relay cir 384000    ! -- Mesma coisa. Confirme com o 
 frame-relay bc 3840       ! Proctor se tem que seguir o SRND e
 frame-relay be 0          ! mudar esses valores para 95% --
 frame-relay mincir 384000
 frame-relay fragment 480
 service-policy output AutoQoS-Policy-Trust

Cálculo da Banda
Pode ser que a prova peça para você permitir na LLQ x chamadas usando G.729 por exemplo. Nesse caso, usar MLPPP ou FRF.12 vai mudar as suas contas. Se você usar MLPPP, o seu overhead de Layer 2 será de 13 bytes. Se usar FRF.12, o overhead é de 6 bytes, de acordo com o SRND. Então atenção com isso na hora de fazer as suas contas.
Se você tiver que configurar FRF.12 e MLPPP no mesmo router, tipo um para a comunicação HQ-BR1 e outra para HQ-BR2, e tiver que configurar bandas diferentes nas suas LLQs, vc vai precisar criar uma segunda Policy-Map e mudar no Virtual-Template.
Para mais informações sobre a continha para fazer o cálculo da banda, veja o meu primeiro post, do dia 30/12.

quinta-feira, 10 de maio de 2012

CME Call Blocking

Uma feature muito útil no CME é o Call Blocking. Com essa feature, podemos definir patterns que podem ser bloqueadas pelo sistema em alguns horários... Por exemplo, eu posso fazer com que o sistema bloqueie chamadas DDI nos finais de semana. E o melhor de tudo é que para configurar é meia dúzia de comandinho... às vezes me pergunto por que diabos algumas features tão legais do CME não são implantadas no CUCM. Para fazer isso no CUCM precisamos criar os Time Schedules, Time Periods, criar Partitions, criar Translation Patterns, ordenar a partition nas Calling Search Spaces... mó trabalho! E no CME se faz com alguns comandos...
Enfim, vamos lá. Para configurar os bloqueios, faremos tudo dentro de telephony-services (mas vai funcionar também para telefones SIP)... Então, pegando até um exemplo de um dos labs do IPExpert, digamos que eu queira permitir que os usuários façam chamadas internacionais (Pattern 900T) apenas de Segunda a Sexta das 7h às 19h, e aos sábados das 7h às 13h. Fora disso, essas chamadas devem ser bloqueadas. Para isso, fariamos o seguinte:

telephony-service
 after-hours block pattern 1 900   ! -- Primeiro definimos a pattern
                                   ! -- a ser bloqueada
 after-hours day Sun 12:00 07:00   ! -- E depois criamos os horários
 after-hours day Mon 19:00 06:59   ! -- de bloqueio.
 after-hours day Tue 19:00 06:59
 after-hours day Wed 19:00 06:59
 after-hours day Thu 19:00 06:59
 after-hours day Fri 19:00 06:59
 after-hours day Sat 13:00 12:00

A sintaxe do comando que define os horários de bloqueio é:
after-hours day <Dia da Semana> <Horario de Inicio> <Horario de Fim>
Quando o horário de fim for menor que o horário de início, como no exemplo, ele considera o dia seguinte. Então nesses casos o bloqueio vai até às 06h59 do dia seguinte. 07h em ponto o bloqueio deixa de valer.
Uma outra forma de configurar os horário de bloqueio é com o comando:
after-hours date <Mes> <Dia> <Horario de Inicio> <Horario de Fim>
Dessa forma, conseguimos definir uma data recorrente de bloqueio, ideal para feriados. Tipo:
after-hours date dec 25 0:00 23:59  ! -- Aplica o bloqueio no Natal

Até aqui tudo tranquilo, né? Mas e se um diretor está no escritório de noite e precisa fazer uma chamada internacional? Para isso existe as opções de Call Blocking Override, isto é, podemos definir algumas formas de certos usuários passarem por cima desse bloqueio:

1. PIN Code
É possível criarmos um PIN Code que fará o override do Call Blocking. No exemplo abaixo, o meu PIN será 1234.
telephony-service
 after-hours override-pattern 1234
Feito isso, quando um usuário discar o número bloqueado com um 1234 na frente, o Call Blocking não terá efeito. Então ele deverá discar 1234 + número internacional (900T) para efetuar a chamada. Isso funcionará independente do ramal, quem souber a senha vai conseguir fazer...

2. Liberação por telefone
Digamos que não queremos criar um PIN global, pois depois de 2 dias todo mundo já sabe o esquema. Então podemos configurar a liberação por telefone, e aplicamos apenas nos usuários mais críticos:
ephone X
 after-hours exempt  ! -- Libera o ephone dos bloqueios

3. Liberação temporária
E agora vamos ao nosso terceiro caso. Digamos que agora não querem que o telefone do pessoal mais crítico fique liberado o tempo todo. Eles querem que seja liberado apenas através de um PIN, e que o login fique ativo por um tempo limitado. Para isso configuramos o seguinte:
telephony-service
 login timeout 180 clear 22:00  ! -- O PIN ficará ativo por 180  
                                  -- minutos, e às 22h os logins  
                                  -- serão liberados -- !
ephone X
 pin 12345

Agora nessa situação, o usuário vai precisar apertar o botão Login nos Softkeys do telefone e digitar o seu PIN individual. Feito isso, o telefone vai estar liberado para fazer as chamadas bloqueadas por 3 horas, sendo que às 22h todos serão deslogados.


E agora que está tudo esclarecido sobre Call Blocking e Override no CME, nos passaram mais um requisito. Querem que especificamente a rota 900T nunca seja liberada através dos PINs (situação 1 e 3). E agora? Para isso, adicione o parâmetro 7-24 no seu comando de block pattern:

telephony-service
 after-hours block pattern 1 900 7-24
Assim, essa rota estará sempre bloqueada, exceto para quem tiver o after-hours exempt configurado no ephone.

sexta-feira, 4 de maio de 2012

CUBE - Parte 2 (Configuração)

Agora que já estamos manjando tudo dos conceitos de CUBE (ô!), veremos que a configuração não é nenhum bicho de 7 cabeças. Vamos implementar o exemplo do post anterior. Ou seja, um CUCM, um CME e ambos registrados num Gatekeeper com função de CUBE. O CUCM tem a faixa de ramal 1XXX e o CME 2XXX.

Os endereçamentos IPs do exemplo serão:
CUCM: 172.16.10.10
CME: 192.168.20.10 (loopback 0)
GK: 172.16.10.230

1. CUCM
No CUCM precisaremos primeiramente declarar um Gatekeeper em Device > Gatekeeper. Utilizaremos o IP 172.16.10.230.
Feito isso, criaremos um Inter-Cluster Trunk (Gatekeeper Controlled) chamado gk-trunk (esse é o nome que vai aparecer no gatekeeper identificando o CUCM). Configuramos o Significant Digits em 4, e definimos a CSS apropriada para que as chamadas entrem corretamente. Amarramos o Gatekeeper criado acima, usando como Zone o nome CUCM, e tech-prefix 1#. Para este exemplo, não mexeremos muito com os tech-prefix... isso fica para assunto num próximo post.
Bom, agora é só criarmos uma Route Pattern 2XXX apontando para o gk-trunk.

2. CME
No CME precisaremos configurar a interface para que ela se registre no Gatekeeper. Então vamos aplicar os comandos abaixo:
interface loopback 0
 ip address 192.168.20.10 255.255.255.0
 h323-gateway voip interface
 h323-gateway voip id CME ipaddr 172.16.10.230 1719
 h323-gateway voip h323-id CME
 h323-gateway voip tech-prefix 1#


Pronto, agora que o CME está configurado para se registrar no GK, temos que criar as dial-peers. Bem, precisamos de uma dial-peer de entrada (para as chamadas que chegam do GK) e uma de saída (para as chamadas que vão para o CUCM através do GK). Poderíamos criar 2 dial-peers separadas, para por exemplo, manipular os codecs diferentemente em uma situação e outra. Aqui no exemplo vamos usar tudo G.711 para evitar o uso de transcodes, portanto vou criar tudo em uma única dial-peer:

dial-peer voice 1 voip 
 incoming called-number . ! -- Entrada
 destination-pattern 1... ! -- Saída
 session target ras       ! -- Aponta a saída para o GK
 codec g711ulaw           ! -- Lembre-se que o default é G.729
 no vad                   ! -- "vad is bad"

Certo! O nosso CME já está configurado. Depois que subirmos o Gatekeeper, só não podemos esquecer de voltar aqui e dar o comando gateway, para que ele se registre com o GK. Ah, não se esqueça também de colocar um no-reg nos ephone-dn, para que os ramais do CME não se registrem no GK!

3. CUBE/Gatekeeper
E agora o mais importante: o GK. Primeiramente vamos configurar a interface FastEthernet dele para que o CUBE se registre no Gatekeeper. Sim, ele vai se registrar nele mesmo, mas lembre-se de que devemos encarar os dois como entidades separadas.

interface FastEthernet1/0
 ip address 172.16.10.230 255.255.255.0
 h323-gateway voip interface
 h323-gateway voip id CUBE ipaddr 172.16.10.230 1719
 h323-gateway voip h323-id CUBE

Feito isso, vamos configurar o gatekeeper em si:

gatekeeper
 zone local CUBE ngk.com                   
 zone local CME ngk.com outvia CUBE      ! -- Depois explico o
 zone local CUCM ngk.com outvia CUBE     ! -- invia e outvia
 zone prefix CUCM 1...
 zone prefix CME 2...
 gw-type-prefix 1#* default-technology
 no shutdown

Agora as dial-peers de entrada e saída, que mais uma vez juntei em uma só. Obs: Se você não criar a dial-peer, o CUBE não registra.

dial-peer voice 1 voip
 destination-pattern [12]...
 session target ras
 incoming called-number .
 codec g711ulaw


Bom, agora é só dar comando gateway que você vai ver tudo registrado no gatekeeper:

CUBE#sh gatekeeper endpoints
                    GATEKEEPER ENDPOINT REGISTRATION
                    ================================
CallSignalAddr  Port  RASSignalAddr   Port  Zone Name         Type    Flags
--------------- ----- --------------- ----- ---------         ----    -----
172.16.10.10    1720  172.16.10.10    32793 CUCM              VOIP-GW
    H323-ID: gk-trunk_1
    Voice Capacity Max.=  Avail.=  Current.= 0
192.168.20.10   1720  192.168.20.10   61476 CME               H323-GW
    H323-ID: CME
    Voice Capacity Max.=  Avail.=  Current.= 0
172.16.10.230   1720  172.16.10.230   57128 CUBE              H323-GW
    H323-ID: CUBE
    Voice Capacity Max.=  Avail.=  Current.= 0
Total number of active registrations = 3


Antes de fazermos os testes, recomendo colocarmos esses comandos no CME e no GK:
voice service voip
 allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
 allow-connections sip to sip
O h323 to h323 é fundamental! Os demais é só se você tiver algum telefone SIP registrado.

Agora sim, hora de testar!
Do jeito que configuramos, tanto no sentido CUCM >> CME quanto no sentido CME >> CUCM, o CUBE será utilizado. Isso por causa daqueles comandos outvia que colocamos ao declarar as Zones. Daqui a pouco vou explicar melhor sobre esse comando. Mas veja que quando fizermos uma chamada do CUCM para o CME, o seguinte output será mostrado:

CUBE#sh gatekeeper calls
Total number of active calls = 2.
                         GATEKEEPER CALL INFO
                         ====================
LocalCallID                        Age(secs)   BW
33-44                              10          128(Kbps)
 Endpt(s): Alias                 E.164Addr
   src EP: gk-trunk_1            1001
           CallSignalAddr  Port  RASSignalAddr   Port
           172.16.10.10    1720  172.16.10.10    32793
 Endpt(s): Alias                 E.164Addr
   dst EP: CUBE                  2002
           CallSignalAddr  Port  RASSignalAddr   Port
           172.16.10.230   1720  172.16.10.230   57128
LocalCallID                        Age(secs)   BW
34-44                              10          128(Kbps)
 Endpt(s): Alias                 E.164Addr
   src EP: CUBE                  1001
           CallSignalAddr  Port  RASSignalAddr   Port
           172.16.10.230   1720  172.16.10.230   57128
 Endpt(s): Alias                 E.164Addr
   dst EP: CME                   2002
           CallSignalAddr  Port  RASSignalAddr   Port
           192.168.20.10   1720  192.168.20.10   61476

Repare que essa é apenas 1 chamada, porém o CUBE exibe como se fosse duas! Uma do CUCM (gk-trunk) para o CUBE e outra do CUBE para o CME. Se fizessemos a chamada do CME para o CUCM, o output seria similar.

Legal, mas por que isso? É que quando declaramos as zones, colocamos o comando outvia CUBE na frente. O que esse comando faz é instruir o GK a enviar a chamada para a zone CUBE quando ela sair do GK. Existe duas formas de configurarmos isso, uma é dessa forma com o comando outvia e outra é com o comando invia.
O outvia, como eu disse, é quando a chamada sai do GK. E o invia, por sua vez, é quando a chamada entra no GK. Poderiamos ter sido orientados a utilizar o CUBE apenas nas chamadas do CUCM para o CME, por exemplo. Nesse caso, o fluxo seria assim: CUCM >> GK >> CME, certo? Então, poderíamos configurar isso aplicando o invia CUBE na zone CUCM ou aplicando o outvia CUBE na zone CME. Funcionaria das duas formas... só que o invia CUBE no CUCM forçaria o uso do CUBE para tooodas as chamadas que chegassem no GK pela zone CUCM, assim como o comando outvia CUBE na zone CME aplicaria o CUBE para tooodas as chamadas que saíssem para o CME.

Se aplicassemos uma dessas configurações, o nosso gatekeeper ficaria assim, por exemplo:
gatekeeper
 zone local CUBE ngk.com
 zone local CME ngk.com
 zone local CUCM ngk.com invia CUBE
 zone prefix CUCM 1...
 zone prefix CME 2...
 gw-type-prefix 1#* default-technology
 no shutdown

Portanto nessa situação, o CUBE seria utilizado apenas nas chamadas que entrassem no GK pelo CUCM. Logo, apenas nas chamadas CUCM >> GK >> CME. Se tivessemos uma outra zone CME2, por exemplo, as chamadas para ela também utilizariam o CUBE. O output do show gatekeeper calls seria o mesmo que o mostrado acima.
Agora, nessa situação, quando fizermos uma chamada do CME para o CUCM, o CUBE não será chamado, e a ligação vai passar direto, veja:

CUBE#sh gatekeeper calls
Total number of active calls = 1.
                         GATEKEEPER CALL INFO
                         ====================
LocalCallID                        Age(secs)   BW
37-46133                           4           128(Kbps)
 Endpt(s): Alias                 E.164Addr
   src EP: CME                   2002
           CallSignalAddr  Port  RASSignalAddr   Port
           192.168.20.10   1720  192.168.20.10   61476
 Endpt(s): Alias                 E.164Addr
   dst EP: gk-trunk_1            1001
           CallSignalAddr  Port  RASSignalAddr   Port
           172.16.10.10    1720  172.16.10.10    32793

E com isso termino a explicação sobre CUBE. Recomendo fortemente que faça isso em um lab, que o entendimento fica bem mais fácil! :)
E recomendo também esse artigo! O cara é foda... e explica só um pouquinho melhor que eu! hauhauhua!



quinta-feira, 3 de maio de 2012

CUBE - Parte 1 (Conceitos)

Configuração de CUBE é um dos temas mais complicados da prova, na minha opinião. Isso porque quase não implementamos no dia-a-dia, e também porque esse assunto estava lá no finalzinho do livro do CVOICE... hehehe! Aí passamos meio batido. Nesse post vou tentar esclarecer um pouquinho sobre os conceitos de CUBE e Via Zones.

Vamos supor que temos duas empresas distintas, uma com um CUCM e outra com um CME. E elas querem fazer a integração da telefonia. Bom, isso seria bem tranquilo, não? Poderiamos criar um trunk H.323 e apontar direto as rotas de um sistema para o outro. Só que a vida não é assim tão fácil... nos passaram um requisito de que eles não querem que seja trocada sinalização diretamente entre os dois dispositivos... O que é bem aceitável, pois poderiamos ter problemas de segurança, roteamento, etc. Então precisamos de um cara que fique no meio do caminho, interceptando a comunicação entre as duas pontas, e fazendo com que o CUCM e CME não se falem diretamente.  É justamete aí que entra o CUBE (Cisco Unified Border Element). Esse produto no mercado é também conhecido como SBC (Session Border Controller). Logo, o CUBE é o SBC da Cisco.

O CUBE essencialmente é um Gatekeeper... e nele vamos configurar 3 zones: ZoneCUCM, ZoneCME e ZoneCUBE. Em termos de configuração, o CUBE é o mesmo device físico que o Gatekeeper, porém é mais fácil pensarmos nele como se fosse uma entidade separada.

Bom, vamos ao nosso Call Setup. Para o exemplo, vamos considerar que o range de ramal do CUCM é 1XXX e o do CME é 2XXX.
Quando o CUCM for fazer uma chamada para o CME, ele enviará um ARQ (Admission Request) para o Gatekeeper, que verificará na sua lista para qual zone irá rotear a chamada. Ele vê que as chamadas para 2XXX devem ser roteadas para a ZoneCME, mas ao invés de enviar a chamada para essa Zone, ele manda ela para ZoneCUBE (veremos o porquê nas configurações). Portanto, quando o Gatekeeper responde o ACF (Admission Confirm) para o CUCM, ele manda o IP do CUBE, e não do CME! Dessa forma, a sinalização H225 é fechada entre o CUCM e o CUBE (que é o Gatekeeper). Essa é a sacada, porque o CUCM nunca recebe o IP do CME para trocar mídia e sinalização. Se pensarmos que o CME está em uma outra empresa, com outro endereçamento, isso faz todo o sentido do mundo, não?
Continuando, quando o CUCM faz o Call Setup com o CUBE, o CUBE manda um outro ARQ para o Gatekeeper (sim, o CUBE e o GK são o mesmo roteador. Na prática, ele manda a mensagem para ele mesmo. Mas lembre-se que devemos sempre encarar o CUBE e o GK como duas entidades separadas). E o Gatekeeper agora responde um ACF, e o CUBE fecha o H225 com o CUCM. Nesse ponto da chamada, a perna CUCM - CUBE já está ok, agora ele vai estabelecer a outra perna (CUBE - CME).
O CUBE agora manda um novo ACF para o Gatekeeper solicitando uma chamada para o CME. O Gatekeeper então responde um ACF para o CUBE, que faz o setup do H225 com o CME. Ao receber esse setup, o CME manda também um ARQ para o GK perguntando se ele pode aceitar a chamada, e o GK responde um ACF autorizando o call setup.
Quando a chamada é estabelecida, o audio pode trafegar de duas formas entre as duas pontas. Uma é o media flow through (default), que separa o RTP em 2 (CUCM-CUBE e CUBE-CME) e o media flow around, que faz um bypass no CUBE e fecha direto entre as duas pontas.
A topologia abaixo mostra tudo o que eu acabei de escrever. Ela foi retirada de uma apresentação do Mark Snow para o Internetwork Expert.



Ok, ficou confuso! Mas tudo isso foi para falar que quando usamos o CUBE, o Gatekeeper intercepta a chamada através de uma zone especial chamada de via zone. E as duas pontas nunca se falam diretamente. Veremos que em uma chamada assim, quando damos um show gatekeeper calls, o output nos mostras duas chamadas ao invés de uma.

Dada essa (tentativa de) explicação, no próximo post vou escrever o que interessa mais para nós: as configurações.