Mudanças entre as edições de "RMU-2012-2"

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
 
(291 revisões intermediárias por 3 usuários não estão sendo mostradas)
Linha 1: Linha 1:
−
= Redes Multimidia: Diário de Aula 2012-1 =  
+
= Redes Multimidia: Diário de Aula 2012-2 =  
  
 
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]
 
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]
Linha 7: Linha 7:
  
 
* [[RMU-ementa|Ementa]]
 
* [[RMU-ementa|Ementa]]
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/plano-de-ensino.pdf Plano de ensino]
+
<!-- * [http://tele.sj.ifsc.edu.br/~msobral/rmu/plano-de-ensino.pdf Plano de ensino]-->
  
 
== Bibliografia ==
 
== Bibliografia ==
Linha 19: Linha 19:
  
 
== Curiosidades ==
 
== Curiosidades ==
 +
 +
* [http://www.sans.org/reading_room/whitepapers/firewalls/ Textos técnicos sobre firewalls]
  
 
== Listas de exercícios ==
 
== Listas de exercícios ==
Linha 32: Linha 34:
 
  !Trabalho Firewalls
 
  !Trabalho Firewalls
 
  !FINAL
 
  !FINAL
 +
|-
 +
|Ana Paula || C ||C || C|| C||? ||I
 +
|-
 +
|André || B ||A || B|| A||C ||B
 +
|-
 +
|Emanuel || D*/D || B||D/D ||D* ||? ||D
 +
|-
 +
|Fabiano || C ||C ||D/B || C||? ||I
 +
|-
 +
|Kalvim || C || B||B ||C || B||B
 +
|-
 +
|Leandro || D || B||D ||C || ?||D
 +
|-
 +
|Liamari || D ||D || D|| C|| ?||D
 +
|-
 +
|Luiz Gustavo || C || C|| B|| A|| C||C
 +
|-
 +
|Maicky || C ||D/D || D*/D|| A||C ||D
 +
|-
 +
|Marine || D/C ||C ||D*/D ||C || ?||D
 +
|-
 +
|Mário || D/B || C||C ||A || B||B
 
  |}
 
  |}
  
Linha 73: Linha 97:
 
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/videos/video3.html Video 3]: usando HTML5
 
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/videos/video3.html Video 3]: usando HTML5
 
* '''Video 4:''' execute '''''vlc''' http://tele.sj.ifsc.edu.br/~msobral/rmu/videos/x.mp4''
 
* '''Video 4:''' execute '''''vlc''' http://tele.sj.ifsc.edu.br/~msobral/rmu/videos/x.mp4''
−
* '''Video 5:''' execute '''''vlc''' http://mmsobral.no-ip.org:8080/armacao/coisas/sr.mp4''
+
* '''Video 5:''' execute '''''vlc''' http://mmsobral.no-ip.org:8080/armacao/coisas/slalom.avi''
−
* '''Video 6:''' execute '''''vlc''' http://mmsobral.no-ip.org:8080/armacao/coisas/sr3.mp4''
+
* '''Video 6:''' execute '''''vlc''' http://mmsobral.no-ip.org:8080/armacao/coisas/slalom2.avi''
  
 
'''Como é feito o acesso a esses videos, e como eles são transportados pela rede ?'''
 
'''Como é feito o acesso a esses videos, e como eles são transportados pela rede ?'''
Linha 117: Linha 141:
 
* XVID
 
* XVID
 
* Theora
 
* Theora
 +
 +
Exemplos de formatos de video usados em MPEG2 (i.e. em DVD):
 +
[[imagem:Mpeg2-video-formats.png]]
  
 
=== Atividade ===
 
=== Atividade ===
Linha 129: Linha 156:
  
 
3) Compare os tamanhos dos arquivos de video resultantes das codificações. Toque-os e veja se há diferença de qualidade de imagem entre eles.
 
3) Compare os tamanhos dos arquivos de video resultantes das codificações. Toque-os e veja se há diferença de qualidade de imagem entre eles.
 +
 +
4) Um software de processamento de video disponível para Linux se chama [http://gopchop.sourceforge.net/ gopchop]. Abaixo segue um texto explicativo sobre esse programa:
 +
 +
[[imagem:Gopchop.png]]
 +
 +
Interprete as informações contidas no texto acima, e experimente usar o ''gopchop''.
  
 
== TAREFA: mecanismos de distribuição de midia ==
 
== TAREFA: mecanismos de distribuição de midia ==
Linha 142: Linha 175:
 
* ... outros ?
 
* ... outros ?
  
−
'''IMPORTANTE:''' Na próxima aula (07/03) sortearei dois alunos para que apresentem seus trabalhos. Se fizerem uma boa apresentação ficarão com crédito (que poderá melhorar seu conceito final). Se não apresentarem ou não trouxerem um bom material, ficarão com um ponto negativo (i.e. conceito final pode ser arredondado pra baixo).
+
'''IMPORTANTE:''' Na próxima aula (16/10) sortearei dois alunos para que apresentem seus trabalhos. Se fizerem uma boa apresentação ficarão com crédito (que poderá melhorar seu conceito final). Se não apresentarem ou não trouxerem um bom material, ficarão com um ponto negativo (i.e. conceito final pode ser arredondado pra baixo).
 +
 
 +
=== Sobre distribuição P2P ===
 +
 
 +
* [http://en.wikipedia.org/wiki/P2PTV P2PTV]
 +
* [http://tools.ietf.org/id/draft-gu-ppsp-peer-protocol-03.txt Peer to Peer Streaming Protocol]
  
 
= 11/10: Caracterização de midias =
 
= 11/10: Caracterização de midias =
Linha 159: Linha 197:
 
* Uso de psicoacústica
 
* Uso de psicoacústica
 
* Remoção de redundância
 
* Remoção de redundância
−
 
  
 
Exemplo de codificação:
 
Exemplo de codificação:
  
 
[[imagem:Audio-codec.png|600px]]
 
[[imagem:Audio-codec.png|600px]]
−
 
  
 
=== Atividade ===
 
=== Atividade ===
Linha 171: Linha 207:
  
 
2) Codifique esse arquivo com os seguintes codecs:
 
2) Codifique esse arquivo com os seguintes codecs:
−
* '''PCM:''' time mplayer -vc dummy -vo null -af format=s8,resample=8000:0:0,channels=1,volume=0 -ao pcm:waveheader:file="musica2.wav" musica.wav
 
 
* '''MP3:''' time lame musica.wav musica.mp3
 
* '''MP3:''' time lame musica.wav musica.mp3
 
* '''Ogg:''' time oggenc -o musica.ogg musica.wav
 
* '''Ogg:''' time oggenc -o musica.ogg musica.wav
Linha 231: Linha 266:
 
[[imagem:Atraso-de-reproducao-adaptativo-2.png|400px]]
 
[[imagem:Atraso-de-reproducao-adaptativo-2.png|400px]]
  
−
==== Atividade ====
+
=== Exercícios ===
  
−
Quais devem ser o atraso e variação de atraso do streaming de video que fizemos na [[RMU-2012-1#Exemplo_1:_video_streaming|aula de 29/02]] ? Poderíamos estimar essas características de transmissão para o [http://tele.sj.ifsc.edu.br/~msobral/rmu/tahiti.mp4 video] que estava em um servidor dentro do IF-SC São José, e para [http://mmsobral.no-ip.org:8080/armacao/coisas/sr.avi aquele outro] que estava em um computador fora da escola.
+
Resolver os exercícios contidos no final das [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-02.pdf transparências].
  
−
# Qual deveria ser o atraso de reprodução mínimo, em cada caso, para que o video pudesse ser reproduzido sem perdas ?
+
= 16/10: Transmissão de dados multimidia =
−
# Qual seria o valor desse atraso mínimo, se fosse calculado segundo o procedimento para determinar o atraso de reprodução adaptativo ?
 
  
−
=== Estratégias para abrandar a perda de mensagens ===
+
* Não houve aula ... fomos ver a apresentação de TCC1 no auditório.
  
 +
== Atividade: atraso de reprodução (extra ... fazer fora da aula) ==
  
−
Reprodução de mensagens perdidas inadequada para aplicações interativas
+
Use [http://tele.sj.ifsc.edu.br/~msobral/rmu/videos/playbuffer.py este programa] para simular um buffer de reprodução com atraso fixo. Para testá-lo faça o seguinte
−
* Mensagens que realmente não chegaram
+
# Execute-o com o comando: <syntaxhighlight lang=bash>
−
* Mensagens que chegaram após instante de reprodução
+
python playbuffer.py
 +
</syntaxhighlight>
 +
# Visualize o video transferido por esse buffer: <syntaxhighlight lang=bash>
 +
mplayer slalom2.mpg
 +
</syntaxhighlight>
 +
# Experimente variar o atraso de reprodução, editando o programa e redefinindo a variável global ''Atraso''. Teste colocá-la com o valor ''0'' para desativar o atraso de de reprodução.
  
  
−
Técnicas para abrandar a perda de mensagens e preservar uma boa (?!) qualidade de áudio
+
Quais devem ser o atraso e variação de atraso do streaming de video que fizemos na [[RMU-2012-2#Exemplo_1:_video_streaming|aula de 04/10]] ? Poderíamos estimar essas características de transmissão para o [http://tele.sj.ifsc.edu.br/~msobral/rmu/tahiti.mp4 video] que estava em um servidor dentro do IF-SC São José, e para [http://mmsobral.no-ip.org:8080/armacao/coisas/slalom2.mpg aquele outro] que estava em um computador fora da escola.
−
* Correção antecipada de erros (FEC - Forward Error Correction)
 
−
* Intercalação
 
  
−
==== Correção antecipada de erros ====
+
# Qual deveria ser o atraso de reprodução mínimo, em cada caso, para que o video pudesse ser reproduzido sem perdas ?
 +
# Qual seria o valor desse atraso mínimo, se fosse calculado segundo o procedimento para determinar o atraso de reprodução adaptativo
  
−
Emissor envia dados redundantes em suas mensagens, também conhecidos como um '''código de correção de erro'''.
+
= 18/10: VoIP e Asterisk =
  
−
'''Exemplo 1:''' envio de uma mensagem redundante para cada grupo de ''n'' mensagens. A mensagem redundante é calculada fazendo '''XOR''' das demais mensagens do grupo.
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-25.pdf Transparências]
−
* Tolera a perda de 1 mensagem
+
* [http://www.asterisk.org Site oficial do Asterisk]
−
* Aumento de banda de ''1/n''
+
* [http://www.asteriskguru.com/ Asterisk Guru]
 +
* [http://www.voip-info.org/wiki Dicas sobre Asterisk]
 +
* [http://www.asteriskdocs.org/ Livro online gratuito sobre Asterisk]
 +
* [http://www.packetizer.com/ipmc/sip/papers/understanding_sip_voip/ Introdução a VoIP e SIP]
 +
* Livro [http://www.voffice.com.br/index.php/pt/noticiasgrupovoffice/voffice-treinamento/96-voffice-lanca-quinta-geracao-do-guia-de-configuracao-para-o-asterisk- ''Asterisk: Guia de Configuração - 5a geração''], de Flávio Gonçalves.
  
−
[[imagem:Rmu-fec.png|400px]]
 
−
<br>''Uso de mensagem redundante com '''XOR'''''
 
  
 +
'''Asterisk:''' uma solução completa de PABX baseado em software, permitindo ligar o mundo IP ao mundo da rede pública de telefonia comutada.
  
−
'''Exemplo 2:''' envio de fluxos redundantes de diferentes qualidades.
+
'''Características Básicas:''' faz tudo que um PABX pequeno e simples faz e pouco mais
−
* Pode-se enviar um fluxo de qualidade inferior junto com o fluxo principal.
+
*ˆ Transferência, música de espera, siga-me, etc.
 +
* Conferência, correio de voz, URA, fila de chamadas, monitoramento de chamadas, integração com o Jabber (Google talk)
  
−
==== Intercalação ====
+
'''Características Avançadas:''' o que seria interessante para grandes empresas
 +
* Uso de banco de dados (MySQL), integração com o LDAP, DUNDi, DNS SRV, geração de bilhetagem
  
  
−
Consiste no resequenciamento das unidades de áudio antes de transmiti-las, de forma que unidades que estavam originalmente próximas sejam separadas por uma certa distância no fluxo a ser transmitido.
+
[[imagem:Asterisk-ex1.png|400px]]
 +
<br>''Exemplo de cenário de uso do Asterisk''
  
−
No exemplo abaixo, cada unidade de áudio tem 5 ms, e cada mensagem contém quatro unidades (totalizando 20 ms).
 
  
 +
<!-- [[imagem:Asterisk-arch.png|500px]]
 +
<br>''Arquitetura modular do Asterisk'' --->
  
−
[[imagem:Rmu-intercalacao.png|400px]]
+
== Plano de discagem ==
  
−
=== Exercícios ===
+
O plano de discagem define como cada chamada deve ser processada. As instruções de processamento residem no arquivo de configuração extensions.conf. O fluxo de processamento de chamadas pode ser visto resumidamente abaixo:
  
−
Resolver os exercícios contidos no final das [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-02.pdf transparências].
+
[[imagem:Asterisk-fluxo.png|400px]]
  
−
= 16/10: Introdução à qualidade de serviço (Qos) =
 
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-03.pdf Transparências]
+
Um exemplo de plano de discagem simples pode ser visto abaixo:
−
* [http://pt.scribd.com/doc/57127868/39/TCP-Global-Synchronization-The-Need-for-Congestion-Avoidance The Need for Congestion Avoidance (slides da Cisco)]
 
  
−
Como medir a qualidade de serviço de uma rede ?
+
<syntaxhighlight lang=text>
−
* Disponibilidade ?
+
[alunos]; o nome deste contexto
−
* Largura de banda
 
−
* Latência (atraso fim-a-fim)
 
−
* Variação de atraso (jitter)
 
−
* Perda de pacotes
 
  
 +
# Chamadas para o número 101 são feitas via SIP para o canal "maria"
 +
exten=>101,1,Dial(SIP/maria)
 +
same=>n,Hangup()
  
−
[[imagem:Rmu-tabela-qos.png]]
+
# Chamadas para "teste" serão atendidas com um som de beep, seguido
−
<br>''Um comparativo de requisitos de QoS de algumas aplicações''
+
# da reprodução do arquivo de som "hello-world", em seguida outro beep e
 +
# enfim se encerra a chamada.
 +
exten=>teste,1,Playback(beep)
 +
same=>n,Wait(1)
 +
same=>n,Playback(hello-world)
 +
same=>n,Wait(1)
 +
same=>n,Playback(beep)
 +
same=>n,Hangup
 +
</syntaxhighlight>
 +
 
 +
A estrutura do plano de discagem é composta por ''extensões'' (um termo específico do Asterisk). Cada extensão identifica um número (ou usuário) que  pode ser chamado, e como essa chamada deve ser processada. A sintaxe pode ser vista abaixo:
  
 +
<syntaxhighlight lang=text>
 +
exten=>identificador,prioridade,aplicação
 +
</syntaxhighlight>
  
−
'''Sumário:'''
+
* '''identificador''': o número ou usuário chamado
−
* ''Classes de serviços''
+
* '''prioridade''': a prioridade da extensão. Isso determina a ordem de execução das extensões que tratam do mesmo identificador.
−
* ''Escalonamento de filas:'' FIFO, Prioridades, Round-robin, WFQ
+
* '''aplicação''': uma ação a ser realizada quando a extensão for processada. Por exemplo, a aplicação ''Dial'' determina que deve ser encaminhada a outro canal.
−
* ''Condicionamento de tráfego:'' balde furado, balde furado com fichas
 
  
−
== Uma pequena experiência ==
+
Como o processamento de uma chamada usualmente envolve uma sequência de extensões, existe uma sintaxe opcional para simplificar a declaração:
  
−
Nessa experiência, todos vão realizar um download simultâneo de um grande arquivo. Enquanto isso, um dos alunos vai visualizar um video via ''streaming''.
+
<syntaxhighlight lang=text>
−
# Para fazer o download: execute '''''wget''' <nowiki>http://tele.sj.ifsc.edu.br/~msobral/ubuntu.iso</nowiki>''
+
exten=>identificador,prioridade,aplicação
−
# Para ver o video: execute '''''vlc''' <nowiki>http://172.18.200.251/~msobral/video.mkv</nowiki>''
+
same=>prioridade,aplicação
 +
</syntaxhighlight>
  
−
* Qual a taxa de download que foi obtida ?
+
*'''same''': declara uma nova extensão com mesmo identificador da extensão imediatamente anterior
−
* Como se desempenhou a reprodução do video ?
 
  
 +
Por fim, a ''prioridade'' (que define a ordem com que as extensões são processadas) declarada com o valor ''n'' equivale à prioridade da extensão imediatamente anterior incrementada em uma unidade:
  
−
A reprodução do video poderia ser preservada se a rede priorizasse seu tráfego. Assim, uma forma de priorização será definida no gateway do laboratório. Após essa modificação, repitam os downloads do arquivo e reprodução do video.
+
<syntaxhighlight lang=text>
 +
exten=>101,1,Dial(SIP/101)
 +
same=>n,Hangup; a prioridade aqui terá o valor 2
 +
</syntaxhighlight>
  
−
* Qual a nova taxa de download obtida ?
+
== Canais SIP ==
−
* Como se desempenhou a reprodução do video desta vez ?
 
  
−
== TAREFA: leitura de um texto ==
+
Cada telefone SIP deve ter seu identificador cadastrado no Asterisk. O identificador pode tanto ser um número, análogo a um ramal, ou uma string alfanumérica. No terminologia do Asterisk, cada telefone SIP é chamado de ''canal SIP'', e deve estar declarado em /etc/asterisk/sip.conf:
  
−
Leiam este texto sobre um problema relacionado aos atrasos de transmissão percebidos na Internet:
+
<syntaxhighlight lang=text>
 +
; Canal 2000 (um exemplo)
 +
[2000]
 +
username=2000 ; o nome do usuário para fins de autenticação
 +
secret=kabrum
 +
type=friend ; pode efetuar e receber chamadas
 +
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
 +
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 +
passo),
 +
                    ; assim como acontece em sessões Web
 +
context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá
 +
disallow=all
 +
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
 +
guida,
 +
          ; já que cada um deles tem suas particularidades.
 +
allow=alaw ; outro codec
 +
allow=ulaw ; mais um codec
 +
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.
  
−
* [http://cacm.acm.org/magazines/2012/2/145415-bufferbloat-whats-wrong-with-the-internet/fulltext Bufferbloat: What is wrong with the Internet ?]
+
; Canal joao (outro exemplo)
 +
[joao]
 +
username=joao ; o nome do usuário para fins de autenticação
 +
secret=blabla
 +
type=friend ; pode efetuar e receber chamadas
 +
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
 +
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 +
passo),
 +
                    ; assim como acontece em sessões Web
 +
context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá
 +
disallow=all
 +
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
 +
guida,
 +
          ; já que cada um deles tem suas particularidades.
 +
allow=alaw ; outro codec
 +
allow=ulaw ; mais um codec
 +
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.
 +
</syntaxhighlight>
  
−
Na aula de 4a feira (14/03) sortearei um aluno para explicar o conteúdo desse artigo.
+
Como se pode notar, a declaração de um canal SIP envolve muitos parâmetros que envolvem autenticação, controle de acesso, localização na rede, codecs e possivelmente outras capacidades. Como os valores de alguns parâmetros podem ser iguais para vários canais, o Asterisk possibilita a declaração de perfis (''templates''):
  
−
Bom fim de semana !
+
<syntaxhighlight lang=text>
−
<!--
+
; Perfil alunos
−
# Obtenha o [http://172.18.200.251/~msobral/itguru.exe instalador do simulador].
+
[alunos](!);  a sequência "(!)" define isto como um perfil
−
# Instale-o em seu computador com o comando '''''wine''' itguru.exe''.
+
type=friend ; pode efetuar e receber chamadas
−
-->
+
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
 +
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 +
passo),
 +
                    ; assim como acontece em sessões Web
 +
context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá
 +
disallow=all
 +
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
 +
guida,
 +
          ; já que cada um deles tem suas particularidades.
 +
allow=alaw ; outro codec
 +
allow=ulaw ; mais um codec
 +
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.
  
−
= 18/10: Simulação com Opnet =
+
; Canal 2000
 +
[2000](alunos); a sequência "(alunos)" copia as definições do perfil "alunos"
 +
username=2000 ; o nome do usuário para fins de autenticação
 +
secret=kabrum
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-04.pdf Roteiro da aula]
+
; Canal joao
 +
[joao](alunos)
 +
username=joao ; o nome do usuário para fins de autenticação
 +
secret=blabla
 +
</syntaxhighlight>
  
−
Hoje serão feitos experimentos com o simulador de redes [http://www.opnet.com Opnet]. Esses experimentos mostrarão os descartes de pacotes, além de atrasos de entrega e variação de atraso, para diferentes disciplinas de enfileiramento nos roteadores.
+
== Atividade ==
  
 +
Para realizar esses exercícios você deve primeiro instalar o Asterisk na máquina virtual ''rmu-server''. Para testar as chamadas, use o softphone jitsy na máquina real.
  
−
* [http://172.18.200.251/~msobral/opnet.tgz Instalador do Opnet (basta descompatar em /home/aluno)]
 
  
 +
# Criar as seguintes contas SIP e contextos:
 +
#*'''alunos''': Contas 100 e 101
 +
#*'''professores''': Contas 200 e 201
 +
#*'''coordenacao:''' Contas 300 e 301<br>{{collapse top | sip.conf}}
 +
<syntaxhighlight lang=text>
 +
[general]
 +
type=friend ; pode efetuar e receber chamadas
 +
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
 +
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 +
passo),
 +
                    ; assim como acontece em sessões Web
 +
disallow=all
 +
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
 +
guida,
 +
          ; já que cada um deles tem suas particularidades.
 +
allow=alaw ; outro codec
 +
allow=ulaw ; mais um codec
 +
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.
  
−
[[imagem:Rmu-opnet.png|600px]]
+
[alunos](!)
 +
context=alunos
  
−
= 23/10: Simulação com Opnet =
+
[professores](!)
 +
context=professores
  
−
Continuação da [[RMU-2012-1#14.2F03:_Simula.C3.A7.C3.A3o_com_Opnet|aula anterior]].
+
[coordenacao](!)
 +
context=coordenacao
 +
 +
[100](alunos)
 +
username=100
 +
secret=100
  
−
Obs: deve-se usar o Crossover para rodar o simulador no Ubuntu 10.04. Para facilitar iniciar o simulador, salve [http://tele.sj.ifsc.edu.br/~msobral/rmu/opnet.sh este script] na sua área de trabalho. Use-o para excutar o simulador.
+
[101](alunos)
 +
username=101
 +
secret=101
  
−
Os modelos de simulação criados na aula passada (pasta ''op_models'') devem ser restaurados em:
+
[200](professores)
 +
username=200
 +
secret=200
  
−
.cxoffice/Unsupported/drive_c/windows/temp/op_models
+
[201](professores)
 +
username=201
 +
secret=201
  
−
== TAREFA: leitura da semana ... ==
+
[300](coordenacao)
 +
username=300
 +
secret=300
  
−
Leiam este textos:
+
[301](coordenacao)
−
*[http://www.informit.com/articles/article.aspx?p=352991&seqNum=8 WRED]
+
username=301
−
*[http://searchnetworking.techtarget.com/tip/LAN-QoS-Access-switches-get-intelligent-for-high-stakes-applications LAN QoS]
+
secret=301
 +
</syntaxhighlight>
 +
{{collapse bottom}}<br>{{collapse top | extensions.conf}}
 +
<syntaxhighlight lang=text>
 +
[alunos]; contexto alunos
 +
; extensoes dos alunos
  
−
As regras são as mesmas: dois alunos serão sorteados para apresentarem explanações sobre esses textos.
+
[professores]; contexto professores
 +
; extensoes dos professores
  
−
= 25/10: IntServ: Serviços Integrados na Internet =
+
[coordenacao]; contexto coordenacao
 +
; extensoes da coordenacao
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-06.pdf Transparências]
+
</syntaxhighlight>
 +
{{collapse bottom}}
 +
# Criar um plano de discagem de forma que as contas SIP do contexto alunos só possam atingir outras contas SIP deste contexto. Faça o mesmo para o contexto professores.ˆ Contas SIP do contexto coordenação poderão atingir, além das contas SIP desse contexto, as contas dos contextos ''alunos'' e ''professores''.
 +
# Execute duas instâncias do Jitsy, sendo que uma delas deve ser configurada para usar a porta 5060, e a outra deve usar a porta 5061. Essas portas servirão para efetuar trocas de mensagens SIP, que é o protocolo usado para iniciar e terminar as chamadas VoIP.
 +
# Adicione uma conta a cada softphone. Use as contas criadas no ítem 1.
 +
# A partir de um softphone faça uma chamada para a conta do outro softphone. Verifique se o softphone destino acusou o recebimento de chamada. Caso isso não tenha ocorrido, verifique seu plano de discagem.
 +
# Execute o wireshark, e ponha-o em modo de captura em todas as interfaces (pseudo-interface ''any'').
 +
# Repita a chamada de um softphone a outro. No softphone destino atenda a chamada, e alguns segundos depois encerre-a.
 +
# No wireshark interrompa a captura, e em seguida acesse o menu ''Telephony->VoIP Calls''. Selecione uma chamada, e visualize o diagrama de mensagens SIP. Siga cada mensagem SIP (clique no diagrama), e observe a mensagem selecionada no painel de captura do wireshark.
  
−
'''IntServ''': serviços integrados para provimento de QoS fim-a-fim. Nesse modelo, fluxos de pacotes entre um  transmissor e um receptor têm seus requisitos de QoS atendidos pela infraestrutura de rede. Para isso, são efetuadas reservas de recursos (largura de banda, priorização) em todos os roteadores ao longo do caminho entre transmissor e um receptor.
+
== TAREFA: Leitura da Semana ==
  
 +
O texto desta semana diz respeito à sinalização SIP, usada em VoIP. Leiam até a página 10  [http://tele.sj.ifsc.edu.br/~msobral/rmu/AlcatelLucent_SIP_Whitepaper.pdf deste artigo], e preparem-se para discuti-lo (e apresentá-lo) nesta 3a feira, 23/10.
  
−
IntServ é introduzido pela [http://tools.ietf.org/html/rfc1633 RFC 1633].
+
<!-- = 18/10: Introdução ao Asterisk (continuação) =
  
 +
== Atividade 1: estabelecendo chamadas ==
  
−
[[imagem:Intserv1.jpeg]]
+
Nesta aula vamos efetuar chamadas entre softphones, e rastrear as trocas de mensagens realizadas durante uma chamada. Serão usadas as contas criadas na aula anterior.
 +
# Execute duas instâncias do Jitsy, sendo que uma delas deve ser configurada para usar a porta 5060, e a outra deve usar a porta 5061. Essas portas servirão para efetuar trocas de mensagens SIP.
 +
# Adicione uma conta a cada softphone. Use contas diferentes dentre aquelas criadas na aula anterior.
 +
# A partir de um softphone faça uma chamada para a conta do outro softphone. Verifique se o softphone destino acusou o recebimento de chamada. Caso isso não tenha ocorrido, verifique seu plano de discagem.
 +
# Execute o wireshark, e ponha-o em modo de captura em todas as interfaces (pseudo-interface ''any'').
 +
# Repita a chamada de um softphone a outro. No softphone destino atenda a chamada, e alguns segundos depois encerre-a.
 +
# No wireshark interrompa a captura, e em seguida acesse o menu ''Telephony->VoIP Calls''. Selecione uma chamada, e visualize o diagrama de mensagens SIP. Siga cada mensagem SIP (clique no diagrama), e observe a mensagem selecionada no painel de captura do wireshark.
 +
#* Observe o tipo de mensagem (o comando SIP)
 +
#* Analise os cabeçalhos SIP
 +
#* Quando disponível, analise a descrição de midia contida nessas mensagens (isso é, veja as mensagens SDP encapsuladas).
 +
#* Identifique as características da stream de audio, e os correspondentes cabeçalhos RTP.
 +
-->
  
 +
<!-- == Atividade 2: estabelecendo chamadas entre diferentes PBX Asterisk ==
  
−
Elementos da arquitetura IntServ:
+
Nesta atividade, vamos realizar chamadas entre softphones registrados em diferentes PBX Asterisk. Para isso, precisaremos estruturar o laboratório da seguinte forma:
−
* '''Especificação de fluxo:''' define as características de um fluxo e os recursos que ele precisa da rede:
+
-->
−
** '''''TSpec (Traffic Specification)''''': especificação de características de um fluxo (gerada pelo transmissor): ''TokenBucketRate, TokeBucketSize, PeakRate, MinimumPolicedUnit, MaximumPacketSize''
 
−
** '''''RSpec (Reservation Specification):''''' especificação de características de uma reserva de recursos (gerada pelo receptor). Contém os mesmos parâmetros que TSpec, além de uma classe de serviço (garantida, carga controlada ou melhor-esforço) e um filtro que descreve o fluxo (endereços IP dos pares, ports TCP ou UDP).
 
−
* '''RSVP (Resource Reservation Protocol):''' protocolo de sinalização para negociar reservas de recursos ao longo do caminho a ser usado pelo fluxo.
 
  
 +
= 23/10: A sinalização SIP e Protocolos de Tempo-Real =
  
−
[[imagem:Intserv-model.jpg]]
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-22.pdf Transparências]
 +
* [http://www.cs.columbia.edu/~hgs/rtp/faq.html Uma FAQ sobre RTP (muito boa)]
  
 +
* '''RTP (''Real Time Protocol''):''' Protocolo de transporte para conteúdo de tempo-real
 +
** Identificação do tipo do conteúdo que está sendo carregado (codec)
 +
** Numeração de sequência
 +
** Marcação de tempo (timestamp) para possibilitar sincronização com a fonte e cálculo de variação de atraso
 +
** Monitoramento da entrega (recepção da stream)
 +
** Não provê garantias de QoS !
 +
* '''RTCP (''Real Time Control Protocol''):''' Protocolo auxiliar ao RTP, para fornecer um feedback dos clientes quanto a streaming.
 +
** Retorno sobre o desempenho da aplicação e da rede
 +
** Informações para sincronização de fluxos de video e áudio
  
−
A sinalização RSVP ocorre em duas etapas:
+
{| border="0" cellpadding="2"
−
# O transmissor do fluxo envia mensagens PATH para o receptor. Essas mensagens contém a descrição do fluxo (''TSpec'').
+
|-
−
# Se aceitar a especificação de fluxo contida na mensagem PATH, o receptor responde com uma mensagem RESV. Essa mensagem especifica a reserva a ser feita ao longo do caminho entre transmissor e receptor (i.e. contém um ''RSpec'') . Cada roteador ao longo do caminho testa se a reserva pode ser satisfeita, e em caso afirmativo propaga a mensagem RESV ao próximo roteador.
+
|[[imagem:Rtp1.png|200px]]<br>''Localização do RTP na camada de transporte'' ||[[imagem:Rtp-header.png]]<br>     ''Cabeçalho RTP''
−
 
+
|}
−
'''Obs:''' o pedido de reserva feito pelo transmissor (mensagens PATH) deve ocorrer ''periodicamente''. Caso os roteadores ou o receptor fiquem um certo tempo sem receber uma mensagem PATH, as reservas correspondentes são canceladas.
 
−
<br>'''Obs 2:''' fluxos são unidirecionais, portanto as reservas são feitas também de forma unidirecional.
 
  
−
[[imagem:Rsvp-signaling.jpg]]
 
  
 +
* [http://en.wikipedia.org/wiki/RTP_audio_video_profile Tabela de tipos de payload RTP]
  
−
Segundo um [http://www.cisco.com/en/US/technologies/tk543/tk766/technologies_white_paper09186a00800a3e2f_ps6610_Products_White_Paper.html artigo da Cisco], IntServ possui como '''pontos fortes''':
+
== Atividade ==
−
* Um tipo de serviço garantido que limita o atraso fim-a-fim e proporciona uma largura de banda para o tráfego que se adequade às especificações da reserva de recursos.
 
−
* Um tipo de serviço de carga controlada, o qual provê um desempenho superior a melhor esforço, além de um atraso fim-a-fim baixo sob cargas leves ou moderadas na rede.
 
−
* Possibilidade de proporcionar a qualidade de serviço pedida para cada fluxo na rede, contanto que tenha sido sinalizado usando RSVP e existam recursos disponíveis.
 
  
 +
Essa atividade busca ilustrar os fluxos RTP com um exemplo:
 +
# Acesse o servidor de streaming de video RTSP usando o aplicativo ''vlc'': <syntaxhighlight lang=bash>
 +
vlc rtsp://172.18.200.251/rmu.sdp
 +
</syntaxhighlight>
 +
# Execute o wireshark e ative a captura de datagramas UDP.
 +
# Observe os pacotes RTP capturados pelo Wireshark. Selecione alguns deles e investigue as informações contidas em seu cabeçalho. Procure identificar o codec usado e as marcações de tempo. Compare as marcações de tempo do RTP com os instantes de recepção desses pacotes.
 +
# Estime o jitter durante a recepção de ao menos 15 segundos de video.
  
−
... mas tem também '''pontos fracos''':
+
= 25/10: A sinalização SIP =
−
* Cada equipamento ao longo do caminho de um pacote, incluindo os sistemas finais (ex: PCs e servidores), precisam entender e usar RSVP e serem capazes de sinalizar a QoS pedida.
 
−
* Reservas de recursos em cada equipamento ao longo do caminho são ''"brandas"'', o que significa que precisam ser renovadas periodicamente. Com isso, há um tráfego de sinalização adicional que contribui para o aumento da carga na rede, o qual aumenta a chance de que a reserva expire se os pacotes de renovação forem perdidos.
 
−
* A manutenção de estados sobre as reservas de reccursos em cada roteador, combinada com controle de admissão e uma maior quantidade de memória necessária para suportar um grande número de reservas, aumenta a complexidade de cada nó da rede ao longo do caminho.
 
−
* Como informação sobre estados para cada reserva precisa ser mantida em todos os roteadores ao longo do caminho, torna-se um desafio manter centenas de milhares de fluxos que passem pelo núcleo da rede.
 
  
−
== Atividade ==
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-22.pdf Transparências]
 +
* [http://www.siptutorial.net/SIP/relation.html Mensagens, Transações, Diálogos e Chamadas SIP]
  
−
Para visualizar o efeito de usar IntServ, iremos utilizar o simulador Opnet.
+
== Atividade 1: Ligação SIP ponto a ponto==
−
# Execute o simulador e abra o modelo ''RSVP''.
 
−
## Leia a descrição do modelo, que explica o que ele pretende mostrar.
 
−
## No menu ''Scenarios->Switch scenario'' selecione ''configuration''. Em  seguida, execute o modelo.
 
−
## Selecione o menu ''Results-Compare results'' para visualizar os resultados, observando os atrasos fim-a-fim nos sistemas finais e nos roteadores.
 
−
## Veja os atributos relativos ao RSVP nos sistemas finais e nos roteadores. Veja também no perfil da aplicação (abra o pop-up menu de ''Application Definition'' e selecione ''Edit Attributes->Application Definitions->VoIP RSVP used->Description''). Além disso, observe as especificações de fluxos RSVP contidas em ''Qos Attribute Config'': abra o pop-up menu, selecione ''Edit Attributes'' e visualize ''RSVP Flow Specification->row 0''.
 
−
# O que acontece se for modificada a especificação de fluxo RSVP ? Experimente aumentar a largura de banda (''TokenBucketRate'') ou tolerância a rajada (''TokenBucketSize''). Isso pode ser feito em ''Qos Attribute Config'': abra o pop-up menu, selecione ''Edit Attributes'' e visualize ''RSVP Flow Specification->row 0''.
 
−
## Execute o modelo com a nova especificação de fluxo.
 
−
## Visualize os resultados. O que mudou em relação à primeira execução ?
 
−
# Qual o efeito de haver um roteador sem suporte a RSVP no meio do caminho ?
 
−
## Duplique o cenário, salvando-o com o nome ''RSVP 2''.
 
−
## Adicione um roteador entre ''Router 1'' e ''Router 2''. Conecte-o a esses outros roteadores com links ''PP DS0''.
 
−
## Refaça a simulação, e observe os resultados. O que mudou em relação ao atraso fim-a-fim ?
 
−
# Ainda sobre o roteador sem RSVP que foi adicionado, faça a seguinte modificação:
 
−
## Conecte o computador ''client_no_RSVP'' ao novo roteador (e desconecte-o de ''Router 1''). Use um link ''PP DS0'.
 
−
## Execute a simulação.
 
−
## Visualize os resultados. O que mudou em relação à simulação anterior (e em relação à primeira simulação) ? Observe especialmente o atraso fim-a-fim.
 
  
 +
# Capturar pacotes com wireshark e analisar mensagens SIP (menu Telephony -> Voip Calls -> Graph)
 +
# Ouvir a conversa capturada (é necessário usar o CODEC G711)
  
−
[[imagem:Rsvp-model-2.png|600px]]
 
−
<br>''O modelo RSVP com mais um roteador.''
 
  
−
<!-- === Sobre o bug no Opnet ===
+
'''Questões:'''
 +
# Qual o CODEC selecionado por cada parte?
 +
# Qual a lista de CODECS?
 +
# Existem mensagens RTCP? Qual a porta?
 +
# Existe algum registro SIP?
 +
# Existe a entidade SIP proxy nesse cenário?
 +
# Existe a entidade RTP proxy nesse cenário?
  
−
Não se pode dizer que seja um ''bug'' no simulador, mas às vezes os resultados da simulação não podem ser visualizados. Quando isso acontece, parece que as estatísticas da simulação não foram coletadas. Mas consegui fazer com que funcionasse (se bem que aninda não entendi ao certo o que causa o problema ... talvez um arquivo de log perdido ?).
 
  
−
'''Solução:'''
+
== Atividade  2: Ligações SIP tendo um PABX Asterisk ==
−
# Remova todo o subdiretório ''.cxoffice'':<syntaxhighlight lang=bash>rm -rf /home/aluno/.cxoffice</syntaxhighlight>
+
# Necessário instalar Asterisk na VM do professor e criar contas SIP para cada aluno
−
# Reinstale o simulador: <syntaxhighlight lang=bash>cd /home/aluno
+
# Capturar pacotes com wireshark e analisar
−
wget http://172.18.200.251/~msobral/opnet.tgz
 
−
tar xzf opnet.tgz</syntaxhighlight>
 
−
-->
 
  
−
= 30/10: DiffServ: Serviços Diferenciados na Internet =
+
'''Questões:'''
 +
# Por que a 1a. tentativa de REGISTER tem como resposta "não autorizado"?
 +
# Existe a entidade SIP proxy nesse cenário?
 +
# Existe a entidade RTP proxy nesse cenário?
 +
#* O fluxo RTP é intermediado?
 +
# Nesse cenário haveria algum problema se uma das partes estiver através de um NAT?
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-06.pdf Transparências]
+
= 30/10: Uma infraestrutura para telefonia com PBX IP =
  
−
Modelo para provimento de QoS para Internet, em que fluxos são ''classificados'' e então tratados de forma ''diferenciada'' dentro da rede. A proposta, contida na [http://www.ietf.org/rfc/rfc2475.txt RFC 2475], visa definir um modelo flexível e escalável para atendimento de requisitos de QoS.
+
Para continuar nosso estudo sobre telefonia IP, usaremos como base o seguinte modelo de rede:
−
* '''Flexibilidade:''' o tratamento de cada classe de tráfego é uma decisão da gerência da rede, e assim não é especificada na proposta.
 
−
* '''Escalabilidade:''' a priorização e condicionamento de tráfego a serem feitos nos roteadores se basearão nas classes de tráfego, e não nos fluxos individuais que passam pela rede (compare com [[RMU-2012-1#21.2F03:_IntServ:_Servi.C3.A7os_Integrados_na_Internet|IntServ]]). Isso proporciona a agregação dos fluxos, que são rotulados com as classes de serviço, facilitando a tarefa dos roteadores no núcleo da rede.
 
  
−
''Obs: as figuras abaixo foram obtidas em um [http://www.cisco.com/en/US/technologies/tk543/tk766/technologies_white_paper09186a00800a3e2f_ps6610_Products_White_Paper.html artigo da Cisco]''
+
[[imagem:Modelo-pbx-asterisk.png|520px]]
  
 +
Esse modelo precisa de alguns componentes para ser implantado:
 +
* PBX IP, representado pelo Asterisk
 +
* Telefones IP ou ''softphones IP'' como o Jitsi
 +
* Telefones convencionais
 +
* Interfaces para integrar telefones convencionais ao PBX IP
 +
* Interfaces para integrar o PBX IP e PSTN por meio de linha analógica ou um tronco E1
  
−
Uma visão geral da arquitetura DiffServ pode ser vista na figura abaixo:
+
A rede de estudo pode ser dividida em uma parte em que as chamadas são efetuadas de forma convencional, e outra parte em que chamadas são feitas com VoIP usando o modelo SIP. O PBX IP consegue atender ambos os tipos de rede telefônica, assim como integrá-los. Desta forma, uma chamada originada em um telefone convencional pode ser destinada tanto a outro telefone convencional quanto a um telefone IP, e vice-versa. A integração entre as duas redes depende, além do PBX IP, de hardware específico.
  
 +
Existem componentes de hardware para possibilitar que um PBX Asterisk se comunique via tronco analógico, digital ou rede celular, além de atender telefones convencionais. Tais componentes provêem os seguintes tipos de interface:
 +
* [http://www.3cx.com/PBX/FXS-FXO.html '''FXS''']: usada para conectar telefones convencionais (POTS), atuando como uma porta de ramal.
 +
* [http://www.3cx.com/PBX/FXS-FXO.html '''FXO''']: usada para comunicação por um tronco analógico (POTS), sendo conectada a uma linha fornecida pela PSTN ou por um PBX analógico (ou pela interface FXS de outro PBX).
 +
* '''E1''': conectada a um tronco E1, que pode ser fornecido pela PSTN ou outro PBX.
 +
* '''GSM''': usada para acesso à rede celular.
  
−
[[imagem:Diffserv-arch.png]]
+
Inicialmente criaremos a infraestrutura para chamadas VoIP, a qual aumentaremos gradualmente para podermos reproduzir o modelo aqui descrito.
−
<br>''Arquitetura DiffServ''
 
  
 +
== Tronco SIP ==
  
−
Diversos elementos compõem a arquitetura:
+
Em um entroncamento SIP (''SIP trunking''), um PBX pode encaminhar chamadas através de um tronco SIP. Essas chamadas podem ser originadas de diferentes formas, tais como telefones IP ou convencionais. Entre os PBX do entroncamento, as chamadas são sinalizadas com SIP e transmitidas com RTP e algum codec.
−
* '''Domínios DiffServ:''' conjuntos de roteadores onde se aplicam uma determinada classificação e diferenciação de tráfego, definidas pela gerência da rede.
 
−
* '''Roteadores de borda:''' roteadores que classificam fluxos que entram num domínio DiffServ. Essa tarefa de classificação e condicionamento de fluxos de entrada pode ser complexa. Por esses roteadores também passam fluxos que saem do domínio, para serem entregues a sistemas finais.
 
−
* '''Roteadores de núcleo:''' roteadores internos de um domínio DiffServ, que encaminham fluxos já classificados. Esses roteadores verificam a conformidade desses fluxos às regras definidas pela gerência da rede para as classes de serviço. Assim, pacotes desses fluxos estão sujeitos a priorizações, enfileiramentos, e mesmo descartes, dependendo das restrições de QoS que foram  definidas. Essas regras compõem o que se chama de ''Comportamento por Salto'' (''PHB - Per-Hop Behaviour''), representada no diagrama contido na figura abaixo.
 
  
 +
[[imagem:Sip-trunk.png]]
  
−
[[imagem:Diffserv-tcb.png]]
+
A ativação de um entroncamento SIP entre dois PBX Asterisk pode ser feita seguindo o exemplo abaixo:
−
<br>''PHB - Per-Hop Behaviour''
 
  
 +
===PBX Norte===
 +
* Arquivo <tt>sip.conf</tt>:<syntaxhighlight lang=text>
 +
; Definição do UAC Sul
  
−
A classificação feita nos roteadores de borda mapeia características dos fluxos para um número de 6 bits. Assim, podem haver até 64 classes de serviço em um domínio DiffServ. Esse número, chamado de ''DSCP - DiffServ Code Point'', é inscrito no campo ToS dos datagramas IPv4 (ou no campo Traffic Class de datagramas IPv6), como mostrado abaixo:
+
[Sul]
 +
type=user
 +
secret=supersercreta
 +
host=IP_PBX_Norte
 +
disallow=all
 +
allow=ulaw
 +
;canreinvite=no
 +
directmedia=no
 +
context=troncoSIP
 +
qualify=yes
  
−
{| border="0" cellpadding="2"
+
[ParaSul]
−
|-
+
type=peer
−
|[[imagem:Ip-tos.png|400px]] ||[[imagem:Dscp.png|400px]]
+
fromuser=Norte
−
|}
+
username=Norte
−
 
+
secret=supersecreta
−
 
+
host=IP_PBX_Sul
−
<!-- [[imagem:Ip-headers.png]] -->
+
disallow=all
−
 
+
allow=ulaw
−
Os comportamentos por salto podem ser:
+
;canreinvite=no
−
* '''Default PHB:''' pacotes com DSCP de valor 000000 (zero) são tratados com melhor esforço. Isso também deve ser aplicado para pacotes cujos DSCP tenham valores não reconhecidos pelo roteador. Ver maiores detalhes na [http://www.ietf.org/rfc/rfc2474.txt RFC 2474].
+
directmedia=no
−
* '''Class-selector PHB:''' pacotes com DSCP xxx000 são tratados de acordo com uma política tradicional de precedência IP (i.e. classes de tráfego descritas no campo ToS). Também descrito na [http://www.ietf.org/rfc/rfc2474.txt RFC 2474]
+
qualify=yes</syntaxhighlight>
−
* '''Expedited Forwarding PHB (EF):''' semelhante ao serviço garantido do IntServ. Desenhado para prover um serviço com baixas taxas de perda, baixa latência e jitter, e uma largura de banda garantida. Deve ser usado somente por aplicações críticas. O valor do DSCP deve ser 10110 (ver [http://www.ietf.org/rfc/rfc2598.txt RFC 2598]
+
* Arquivo <tt>extensions.conf</tt>:<syntaxhighlight lang=text>
−
* '''Assured Forwarding PHB (AF):''' semelhante ao serviço de carga controlada do IntServ. Define quatro classes de serviço, sendo que cada uma tem três níveis de precedência de descarte.
+
...
 +
[troncoSIP]
 +
; Ligando para a outra central e, na sequência, o "ramal" de destino
 +
exten => _0.,1,Dial(SIP/ParaSul/${EXTEN:1})
 +
</syntaxhighlight>
  
 +
===PBX Sul===
 +
* Arquivo <tt>sip.conf</tt>:<syntaxhighlight lang=text>
 +
; Definição do UAC Norte
 +
[Norte]
 +
type=user
 +
secret=supersercreta
 +
host=IP_PBX_Sul
 +
disallow=all
 +
allow=ulaw
 +
;canreinvite=no
 +
directmedia=no
 +
context=troncoSIP
 +
qualify=yes
  
−
[[imagem:Aff-codepoint-table.png]]
+
[ParaNorte]
−
<br>''Classes de serviço e precedências de descarte em AF PHB''
+
type=peer
−
 
+
fromuser=Sul
−
== Atividade ==
+
username=Sul
 +
secret=supersecreta
 +
host=IP_PBX_Norte
 +
disallow=all
 +
allow=ulaw
 +
;canreinvite=no
 +
directmedia=yes
 +
qualify=yes
 +
</syntaxhighlight>
 +
* Arquivo <tt>extensions.conf</tt>: <syntaxhighlight lang=text>
 +
[troncoSIP]
 +
;
 +
; Ligando para a outra central e, na sequência, o "ramal" de destino
 +
exten => _0.,1,Dial(SIP/ParaNorte/${EXTEN:1})
 +
</syntaxhighlight>
  
−
#Vamos fazer a marcação de pacotes que entram na rede do laboratório, de forma que:
+
== Atividade: estabelecendo chamadas entre diferentes PBX Asterisk ==
−
#* Pacotes vindos de servidores da escola devem ter DSCP corresponde à classe AF41.
 
−
#* Pacotes vindos de fora da escola devem ter DSCP AF31. <syntaxhighlight lang=bash>
 
−
iptables -t mangle -I PREROUTING 1 -i eth1 -j DSCP --set-dscp-class af31
 
  
−
iptables -t mangle -A PREROUTING -i eth1 -s 172.18.0.0/16 -j DSCP \
+
Nesta atividade, vamos realizar chamadas entre softphones registrados em diferentes PBX Asterisk. Para isso, precisaremos estruturar o laboratório de forma que cada PBX Asterisk possua um tronco SIP com um PBX vizinho. Os usuários SIP serão identificados por MMXX, sendo ''MM'' o número do computador de cada aluno (ex: micro 2 tem usuários entre 200 e 299). Assim, é possível fazer um plano de discagem para encaminhar corretamente as chamadas.
−
--set-dscp-class af41
 
  
−
iptables -t mangle -A PREROUTING -i eth1 -s 200.135.37.64/26 -j DSCP \
+
= 06/11: Interligando PBX Asterisk =
−
--set-dscp-class af41</syntaxhighlight>
 
−
# Execute o wireshark em seu computador, e observe o valor do DSCP. Ele realmente varia dependendo da origem do pacote ?
 
−
# O que poderia ser feito para usar esse valor para prover QoS na rede do laboratório ?
 
  
−
== TAREFA: RSVP-TE ==
+
Nesta atividade vamos integrar os servidores Asterisk de todos os alunos no laboratório. Usaremos uma estrutura hierárquica como ilustrado abaixo:
  
−
Leia [http://www.ciscopress.com/articles/article.asp?p=426640&seqNum=2 este artigo] da Cisco sobre engenharia de tráfego em redes MPLS. Em particular, estude a seção que trata de RSVP-TE, uma versão do protocolo RSVP adaptada para o uso em MPLS.
 
  
−
= 01/11: Laboratório: roteador Linux =
+
[[imagem:Asterisk-hierarquia-lab2.png]]
  
−
Nesta 2a parte da disciplina pretende-se implantar uma rede com suporte a QoS. Para isso deve-se seguir o modelo [[RMU-2012-1#22.2F03:_DiffServ:_Servi.C3.A7os_Diferenciados_na_Internet|Diffserv]], usando-se roteadores Linux como roteadores de borda e núcleo - i.e. como classificadores e condicionadores de tráfego. No entanto, essa plataforma possui diversas peculiaridades quanto aos mecanismos a serem usados para implantar [[RMU-2012-1#22.2F03:_DiffServ:_Servi.C3.A7os_Diferenciados_na_Internet|Diffserv]]. Para que todos se familiarizem com esses mecanismos e entendam como utilizá-los, além de eles serem apresentados em aula serão feitos exercícios para ilustrá-los.
 
  
−
Nesta aula será feita uma revisão sobre roteadores Linux. Boa parte do que será visto não deve ser novidade para quem fez Redes 3, mas sempre há algum detalhe novo. Serão mostrados comandos e utilitários necessários para configurar interfaces de rede e rotas. Além disso, serão apresentados alguns utilitários para mostrar informações sobre o tráfego nas interfaces de rede, ou para descobrir a capacidade da rede entre dois nós. As atividades a serem desenvolvidas devem fornecer a base para a implantação de mecanismos de Qos nas próximas aulas.
+
Em um primeiro momento, o servidor Asterisk do professor terá o papel de encaminhar chamadas entre os servidores dos alunos. Mas para que isso seja viável e escalável, cada aluno deve usar uma numeração de ramais que possa ser univocamente identificada. Assim, cada servidor Asterisk deve numerar seus ramais da seguinte forma:
  
 +
* ''21XX:'' números do aluno 1
 +
* ''22XX:'' números do aluno 2
 +
* ''23XX:'' números do aluno 3
 +
* ''30XX:'' números do aluno 10
 +
* ''34XX:'' números do aluno 14
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-07.pdf Roteiro]
+
A interligação entre os servidores Asterisk do professor e alunos será implantada por um tronco E1. Para isso serão usados dois [http://www.khomp.com.br/v2/?opcao=ver_produto&id_c=8&id_p=47 módulos EBS da Khomp]. Um dos PBX de alunos deve ser configurado para usar um módulo EBS, e fazer o encaminhamento e recebimento de chamadas via tronco E1. Com isso, todas as chamadas de telefones de diferentes PBX passarão pelo tronco E1 e pelo PBX do professor.  
  
 +
== Questões para refletir ==
 +
# O encaminhamento de chamadas nesse cenário poderia ser melhorado. As chamadas entre ramais de PBX de alunos não precisariam passar pelo tronco E1. O que seria necessário modificar para que isso fosse implantado ?
 +
# E se ao invés do tronco E1 fosse usado um tronco [http://en.wikipedia.org/wiki/Inter-Asterisk_eXchange IAX2] ou SIP ? Que vantagens ou desvantagens existiriam nesse caso ?
  
 +
= 08/11: Prática com Asterisk: aplicações e funções típicas de PBX  =
  
−
[[imagem:Lab-rot-linux.png]]
+
Algumas funções típicas de PBX são:
 +
* Transferência de chamadas
 +
* Captura de chamadas
 +
* Estacionamento de chamadas
 +
* Gravação de chamadas
 +
* Música em espera
 +
* Sala de conferência
 +
* Correio de voz
 +
* Siga-me (se ocupado, imediato ou se não atender)
 +
* Lista negra
 +
* Não perturbe
 +
* Rediscagem
  
−
= 06/11: Laboratório sobre roteador Linux =
+
Essas funcionalidades podem ser implementadas no próprio PBX ou no telefone. No caso do Asterisk, elas podem ser disponibilizadas diretamente pelo próprio Asterisk, ou ser implementadas no plano de discagem. A figura abaixo ilustra essas possibilidades:
  
−
... continuação.
+
[[imagem:Recursos-pbx.png]]
 +
<br>''Funções disponíveis em um PBX Asterisk - figura obtida de: Flávio Gonçalves. Guia de Configuração para Asterisk PBX, 5a edição.''
  
−
= 08/11: Firewall =
+
Para criar essas funções em um PBX Asterisk, é necessário conhecer os recursos que ele oferece. Dentre esses recursos, há aplicações, variáveis, e características (''features''). Hoje serão vistos alguns deses recursos, que usaremos para implantar algumas das funções enumeradas acima.
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-08.pdf Transparências]
+
== Extensões especiais ==
  
−
== Uma introdução ao iptables ==
+
Além das extensões criadas pelo usuário, o Asterisk apresenta algumas extensões especiais, tais como:
 +
* '''s ''(start)'':''' tem por objetivo tratar qualquer chamada que entre em um contexto e que não tenha um destino específico.
 +
* '''i ''(invalid)'':''' tem por objetivo tratar entradas inv ́lidas em um menu interativo
 +
* '''t ''(timeout)'':''' Em um menu interativo intercepta a chamada caso o usuário não forneça uma entrada dentro de um período de tempo estipulado.
  
−
O filtro IP do Linux se chama [http://www.netfilter.org/ NetFilter], e suas regras são configuradas por meio do utilitário [https://help.ubuntu.com/community/IptablesHowTo iptables] (ver também seu [http://manpages.ubuntu.com/manpages/natty/man8/iptables.8.html manual]). Com iptables se podem adicionar ou remover regras do Netfilter, além de consultar estatísticas sobre essas regras (ex: contadores dos pacotes e bytes que selecionaram cada regra). As regras são agrupadas em conjuntos denominados ''chains'' ("cadeias"), as quais estão relacionadas com o contexto que cada pacote está sendo analisado. Existem três ''chains'' predefinidas:
+
== Aplicações ==
−
* '''INPUT:''' contém as regras a serem aplicadas aos pacotes destinados ao próprio firewall.
 
−
* '''OUTPUT:''' contém as regras a serem aplicadas aos pacotes transmitidos pelo próprio firewall.
 
−
* '''FORWARD:''' contém as regras a serem aplicadas aos pacotes em trânsito pelo firewall (isto é, pacotes recebidos de uma interface e sendo encaminhados através de outra interface).
 
−
Assim, usando-se o iptables podem ser adicionadas regras a cada uma dessas ''chains'', dependendo do policiamento de tráfego a ser implantado no firewall.
 
  
 +
As aplicações são usadas no plano de discagem. Assim, o processamento de uma chamada se faz pela execução sucessiva de aplicações, de forma a se obter o efeito desejado.
  
−
[[imagem:Iptables-chains.png|400px]]
+
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+NoOp NoOp] ===
  
 +
Não faz nada, sendo útil para depurar o plano de discagem. Exemplo:
 +
<syntaxhighlight lang=text>
 +
exten=>100,1,NoOp(${CONTEXT})
 +
</syntaxhighlight>
  
−
Uma regra deve especificar basicamente três coisas:
+
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+GoTo GoTo] ===
−
* '''Chain''': em que ''chain'' deve ser adicionada.
 
−
* '''Seletor:''' informações a serem usadas para selecionar os pacotes a que ela deve ser aplicada.
 
−
* '''Alvo (''target''):''' ação a ser executada sobre o pacote que ativar a regra.
 
  
−
Por exemplo, a regra abaixo permite o encaminhamento de todos os segmentos TCP destinados a porta 80:
+
Pula para um contexto (opcional), extensão, prioridade específica. Exemplo:
 +
<syntaxhighlight lang=text>
 +
exten=>100,1,GoTo(vendas,s,1)
 +
</syntaxhighlight>
 +
 
 +
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+GoToIf GoToIf] ===
 +
 
 +
Trata-se do comando GoTo condicional. Sua sintaxe é:
  
 +
'''GoToIf'''''(condição?[rótulo se verdade]:[rótulo se falso])''
  
−
[[imagem:Iptables-intro.png]]
+
Os rótulos podem assumir a forma:
  
 +
  ''[[contexto],extensão,]prioridade''
  
−
Desta forma, a escrita das regras depende de conhecer as opções para definição de seletores, e os possíveis alvos. Algumas opções de uso comum para composição de  seletores são listadas abaixo, sendo que o que está entre colchetes ([]) é opcional. Um seletor pode ser composto por uma combinação dessas opções. Para mais detalhes leia o [http://manpages.ubuntu.com/manpages/natty/man8/iptables.8.html manual].
+
Exemplo:
 +
<syntaxhighlight lang=text>
 +
[alunos]
  
−
{| border="1" cellpadding="2"
+
exten=>6111,1,GoToIf($["${CALLERID(num)}" != "6112"]?2:4)
−
!Opção
+
same=> n,Dial(SIP/6111,30)
−
!Descrição
+
same=> n,Hangup
−
!Exemplo
+
same=> n,Answer
−
|-
+
same=> n,Playback(hello-world)
−
| -s IP[/Mascara] || endereço IP de origem|| -s 200.135.37.64/26
+
same=> n,Hangup
−
|-
+
</syntaxhighlight>
−
| -d IP[/Mascara] || endereço IP de destino|| -d 8.8.8.8
+
 
−
|-
+
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+BackGround Background] ===
−
| -p Protocolo || protocolo de transporte (tcp ou udp) || -p tcp
 
−
|-
 
−
| --dport numero || Port de destino || --dport 80
 
−
|-
 
−
| --sport numero || Port de origem || --sport 53
 
−
|-
 
−
| --syn || Se flag SYN está acesa (somente TCP) ||
 
−
|-
 
−
| --tcp-flags Flags1 Flags2 || Se somente as flags listadas em Flags1 estão acesas dentre as Flags2 || --tcp-flags SYN,ACK,RST,FIN SYN
 
−
|-
 
−
| -i interface || Se pacote foi recebido pela interface || -i eth0
 
−
|-
 
−
| -o interface || Se pacote vai sair pela interface || -o eth1
 
−
|-
 
−
| -m state --state ESTADO || Identifica o estado do fluxo, o qual pode ser:<br>NEW: início de um fluxo<br>ESTABLISHED: parte de um fluxo estabelecido<br>RELATED: inicia um novo fluxo, porém relacionado com um fluxo existente || -m state --state NEW,RELATED
 
−
|}
 
  
 +
Toca um arquivo de som como música de fundo. Esse arquivo deve estar em ''/usr/share/asterisk/sounds'', e ser codificado com codec PCM ou WAV.
  
−
Os alvos definem o que fazer com um pacote selecionado por uma regra. As ações possíveis estão listadas abaixo:
+
Exemplo:
  
 +
<syntaxhighlight lang=text>
 +
exten=>666,1,Answer
 +
same=>n,Background(hello-world)
 +
same=>n,Hangup
 +
</syntaxhighlight>
  
−
{| border="1" cellpadding="2"
+
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Playback Playback] ===
−
!Alvo
 
−
!Descrição
 
−
!Exemplo
 
−
|-
 
−
| ACCEPT || aceita o pacote|| -j ACCEPT
 
−
|-
 
−
| DROP || descarta o pacocte || -j DROP
 
−
|-
 
−
| REJECT || rejeita o pacote, devolvendo um código de erro ICMP para seu remetente || -j REJECT
 
−
|-
 
−
|LOG || registra o pacote no log do sistema || -j LOG
 
−
|-
 
−
|uma_chain || passa o pacote para ser processado pela chain uma_chain || -j rede_interna
 
−
|}
 
  
 +
Toca um arquivo de som. A diferença em relação a Background é que Playback devolve o controle ao Asterisk (i.e. ao plano de discagem) somente após tocar todo o arquivo. Esse arquivo deve estar em ''/usr/share/asterisk/sounds'', e ser codificado com codec PCM ou WAV.
  
−
=== Salvando e restaurando regras do iptables ===
+
Exemplo:
  
−
Uma vez obtido um conjunto de regras que funcione como desejado, deve-se poder salvá-lo para que possa ser reativado sempre que desejado (ex: no boot). Existem dois utilitários que auxiliam nessa tarefa, sendo eles:
+
<syntaxhighlight lang=text>
−
* '''iptables-save''': escreve as regras atuais na saída padrão, que normalmente é redirecionada para um arquivo: <syntaxhighlight lang=bash>
+
exten=>666,1,Answer
−
iptables-save > minhas_regras
+
same=>n,Playback(hello-world)
−
</syntaxhighlight>
+
same=>n,Hangup
−
* '''iptables-restore''': instala as regras lidas da entrada padrão, normalmente redirecionada de um arquivo: <syntaxhighlight lang=bash>
 
−
iptables-restore < minhas_regras
 
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
== Atividade ==
+
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Wait Wait] ===
  
−
Cada aluno deve implantar a seguinte rede virtual em seu computador:
+
Força uma espera durante o processamento da chamada.
  
 +
Exemplo:
  
−
[[imagem:Lab-firewall-intro.png]]
+
<syntaxhighlight lang=text>
 +
exten=>666,1,Answer
 +
same=>n,Playback(hello-world)
 +
same=>n,Wait(1)
 +
same=>n,Playback(beep)
 +
same=>n,Hangup
 +
</syntaxhighlight>
 +
 
 +
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Answer Answer] e [http://www.voip-info.org/wiki/view/Asterisk+cmd+Hangup Hangup] ===
  
 +
Answer atende uma chamada. Hangup termina uma chamada.
  
−
O ''firewall'' e o ''Pc'' devem ser máquinas virtuais. Você pode usar o Virtualbox ou o [[Netkit]]. Se optar pelo segundo, use a seguinte configuração de rede (grave-a em um arquivo chamado ''Lab.conf''):
+
Exemplo:
  
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
−
# Obs: substitua X pelo número do seu computador
+
exten=>666,1,Answer
−
pc[type]=generic
+
same=>n,Playback(hello-world)
−
firewall[type]=gateway
+
same=>n,Hangup
−
 
 
−
pc[eth0]=link:ip=10.1.X.1/24
 
−
firewall[eth1]=link:ip=10.1.X.254/24
 
−
firewall[eth0]=uplink:bridge=eth0:ip=192.168.2.100+X/24
 
−
 
 
−
pc[default_gateway]=10.1.X.254
 
−
firewall[default_gateway]=192.168.2.1
 
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
No caso do [[Netkit]], execute o programa '''gnome-netkit''' para executar a rede virtual. Selecione o menu ''File->Load and run'' e carregue o arquivo ''Lab.conf''.
+
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Set Set] ===
  
−
Se for usado o Virtualbox, use a máquina virtual ''Rmu-server'' para ser o firewall, e ''Rmu-cliente''  para ser o Pc. Inicie-as, certificando-se de que suas interfaces de rede estejam em modo bridge. Configure os endereços IP de suas interfaces e também suas rotas default.
+
Modifica o valor de uma variável.
  
−
=== Cenário 1: Uma rede pequena sem servidores ===
+
Exemplo:
  
−
Em uma rede pequena e que não oferece serviços, todos os fluxos se originam internamente. Assim, o firewall deve impor que somente fluxos internos possam passar. Com base nisso, configure seu firewall das seguintes formas:
+
<syntaxhighlight lang=text>
−
# ''Caso 1:'' os computadores internos podem acessar qualquer serviço externo.
+
exten=>666,1,Set(Tentativas=1)
−
#* Com filtro ''stateless'': <syntaxhighlight lang=bash>
+
same=>2,Dial(SIP/666,10)
−
# As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall
+
same=>3,Set(Tentativas=${Tentativas}+1)
 +
same=>4,GoToIf($[${Tentativas} < 2]?2:5)
 +
same=>5,Hangup
 +
</syntaxhighlight>
  
−
# Libera todos pacotes TCP que entrarem pela interface eth1
+
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Log Log] ===
−
iptables -A FORWARD -i eth1 -p tcp -j ACCEPT
 
  
−
# Libera pacotes UDP destinados a porta 53 (DNS), contanto que tenham entrado pela interface eth1
+
Grava um texto qualquer no log do Asterisk.
−
iptables -A FORWARD -i eth1 -p udp --dport 53 -j ACCEPT
 
  
−
# Libera pacotes UDP com port de origem 53 (resposta do DNS), contanto que tenham entrado pela interface eth0
+
Exemplo:
−
iptables -A FORWARD -i eth0 -p udp --sport 53 -j ACCEPT
 
  
−
# Libera segmentos TCP vindos pela interface eth0 e que tenham as flags SYN e ACK acesas (respsta de pedido de conexão TCP)
+
<syntaxhighlight lang=text>
−
iptables -A FORWARD -i eth0 -p tcp --tcp-flags SYN,ACK SYN,ACK -j ACCEPT
+
exten=>666,1,Log(DEBUG,"Chamada para 666")
 +
same=>n,Dial(SIP/666,10)
 +
same=>n,Hangup
 +
</syntaxhighlight>
  
 +
== Variáveis ==
  
−
# Libera segmentos TCP vindos pela interface eth0 e que não tenham a flags SYN acesa (pertencem a cconexões estabelecidas)
+
O uso de variáveis no Asterisk possui funcionamento semelhante àquele encontrado nas linguagens de programação, permitindo ao “programador” utilizar variáveis já definidas pelo Asterisk bem como definir suas próprias variáveis. As definições das variáveis devem ser feitas no arquivo ''extensions.conf''.
−
iptables -A FORWARD -i eth0 -p tcp ! --syn -j ACCEPT
 
  
−
# Descarta segmentos TCP vindos de fora
+
A sintaxe para trabalhar com variáveis no Asterisk é semelhante a do [http://manpages.ubuntu.com/manpages/hardy/man1/bsd-csh.1.html c-shell], porém as variáveis definidas pelo usuário não são sensíveis a caixa, ou seja, VAR e var referem-se à mesma variável.
−
iptables -A FORWARD -i eth0 -p tcp -j DROP
+
* Para definir uma variável: ''VAR=valor''
−
</syntaxhighlight>
+
* Para obter o valor de uma variável: ''${VAR}''
−
#* Com filtro ''stateful'': <syntaxhighlight lang=bash>
+
 
−
# As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall
+
Existem três tipos de variáveis:
 +
* '''Variáveis globais:''' Variáveis que estarão disponíveis a todos os canais e contextos em um plano de discagem. Essas devem ser declaradas dentro do contexto ''[globals]'' existente no arquivo ''extensions.conf'' ou utilizando a função ''GLOBAL()'' no plano de discagem.
 +
* '''Variáveis do canal:''' Variáveis que estão associadas especificamente com uma unica ligação. São definidas durante a chamada e só estão disponíveis para os participantes desta chamada. O Asterisk já define algumas variáveis específicas ao canal (Ex: ${CALLERID(num)}).
 +
* '''Variáveis de ambiente:''' São as variáveis obtidas do sistema operacional. Estas são referenciadas através do comando ENV. Ex: ''${ENV(path)}.''
  
−
# Libera todos pacotes de fluxos estabelecidos
+
Abaixo se pode ver um exemplo de plano de discagem que usa variáveis:
−
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
 
  
−
# Libera pacotes UDP destinados a porta 53 (DNS), contanto que tenham entrado pela interface eth1
+
<syntaxhighlight lang=text>
−
iptables -A FORWARD -i eth1 -p udp --dport 53 -m state --state NEW -j ACCEPT
+
[globals]
 +
; definicao de uma variavel global
 +
VENDAS=SIP/6112
  
−
# Libera pacotes que iniciem novos fluxos, originados na rede interna (interface eth1)
+
[alunos]
−
iptables -A FORWARD -i eth1 -m state --state NEW,RELATED -j ACCEPT
+
; definicao de uma variavel global atraves do comando Global e aplicacao Set
 +
exten=> 6666,1,Set(GLOBAL(COMPRAS)=SIP/6113)
 +
exten=> 6666,2,NoOp(${GLOBAL(COMPRAS)})
  
−
# Descarta demais pacotes
+
; definicao de uma variavel especifica ao canal
−
iptables -A FORWARD -j DROP
+
exten=> 7777,1,Set(teste=1)
 +
exten=> 7777,n,NoOp(${teste})
 +
exten=> 7777,n,Set(teste=$[${teste} + 1])
 +
exten=> 7777,n,NoOp(${teste})
 +
exten=> 7777,n,Hangup
 
</syntaxhighlight>
 
</syntaxhighlight>
−
# ''Caso 2:'' os computadores internos podem acessar somente serviços Web e DNS. <syntaxhighlight lang=bash>
 
−
# As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall
 
  
−
# Libera todos pacotes de fluxos estabelecidos
+
== Funções implementadas no próprio Asterisk ==
−
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
 
  
−
# Libera datagramas UDP destinados a porta 53 (DNS), contanto que tenham se originado na rede interna
+
=== [http://www.voip-info.org/wiki/view/Music+on+Hold Música de espera] ===
−
iptables -A FORWARD -i eth1 -p udp --dport 53 -m state --state NEW -j ACCEPT
 
  
−
# Libera segmentos TCP destinados as portas 80 (HTTP) e 443 (HTTPS), contanto que tenham se originado na rede interna
+
O Asterisk permite o uso de MP3 como música de espera, porém MP3 são arquivos complicados de se trabalhar pois requerem o uso de aplicações externas para que possam ser reproduzidos, como por exemplo [http://manpages.ubuntu.com/manpages/lucid/man1/mpg123.bin.1.html mpg123]. Seu funcionamento também pode não agradar muito já que em alguns casos a música pode ser reproduzida em alta rotação além de elevar a carga de processamento da máquina no caso de soluções de grande porte.
−
iptables -A FORWARD -i eth1 -p tcp --dport 80 -m state --state NEW -j ACCEPT
 
−
iptables -A FORWARD -i eth1 -p tcp --dport 443 -m state --state NEW -j ACCEPT
 
  
−
# Descarta demais pacotes
+
A partir da versão 1.2 do Asterisk se sugere não mais usar o ''mpg123''. O melhor é converter arquivos MP3 para um formato que o Asterisk trate nativamente, como por exemplo, ''wav'' ou ''pcm'' (μLaw). A ferramenta [http://manpages.ubuntu.com/manpages/karmic/en/man1/ffmpeg.1.html ffmpeg] pode ser usada para converter arquivos MP3 para WAV ou PCM.
−
iptables -A FORWARD -j DROP</syntaxhighlight>
 
−
#* Versão alternativa, usando o módulo ''multiport'': <syntaxhighlight lang=bash>
 
−
# As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall
 
  
−
# Libera todos pacotes de fluxos estabelecidos
+
<syntaxhighlight lang=bash>
−
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
+
# convertendo o arquivo musica.mp3 para musica.wav e musica.pcm
 +
ffmpeg -i musica.mp3 -ar 8000 -ac 1 -ab 64 musica.wav -ar 8000 -ac 1 -ab 64 -f mulaw
 +
musica.pcm -map 0:0 -map 0:0
 +
</syntaxhighlight>
  
−
# Libera datagramas UDP destinados a porta 53 (DNS), contanto que tenham se originado na rede interna
+
Os arquivos de música devem ficar em um diretório especificado para cada contexto, conforme definido no arquivo [http://www.voip-info.org/wiki/view/Asterisk+config+musiconhold.conf ''musiconhold.conf'']:
−
iptables -A FORWARD -i eth1 -p udp --dport 53 -m state --state NEW -j ACCEPT
 
  
−
# Libera segmentos TCP destinados as portas 80 (HTTP) e 443 (HTTPS), contanto que tenham se originado na rede interna
+
<syntaxhighlight lang=text>
−
iptables -A FORWARD -i eth1 -p tcp -m multiport  --dports 80,443 -m state --state NEW -j ACCEPT
+
# configuracao no arquivo musiconhold.conf
−
 
+
[alunos]
−
# Descarta demais pacotes
+
mode=files
−
iptables -A FORWARD -j DROP</syntaxhighlight>
+
directory=/var/lib/asterisk/moh
 +
sort=random
 +
# deve-se colocar os arquivos wav e/ou pcm no diretorio especificado acima
 +
</syntaxhighlight>
  
−
= 13/11: Firewall =
+
Para testar a música em espera no plano de discagem, pode-se usar a aplicação [http://www.voip-info.org/wiki/view/Asterisk+cmd+MusicOnHold MusicOnHold]:
  
−
... continuação da aula anterior: Caso 2 do cenário 1 em diante.
+
<syntaxhighlight lang=text>
 +
exten=>667,1,Set(CHANNEL(musicclass)=alunos)
 +
same=>n,Answer
 +
same=>n,MusicOnHold()
 +
same=>n,Dial(SIP/667)
 +
same=>n,Hangup
 +
</syntaxhighlight>
  
−
== TAREFA: leitura da semana ==
+
=== [http://www.voip-info.org/wiki/view/Asterisk+call+queues Filas de atendimento] ===
  
−
Leia o seguinte texto sobre SLA (Service Level Agreement) e Diffserv, e se prepare para discutir seu conteúdo na aula de 12/04 (5a feira).
+
Amplamente utilizadas nos sistemas de 0800. A configuração é feita no arquivo ''queues.conf'':
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/docs/diffserv-network-edge-1.pdf "Deploying Diffserv at the Network Edge for Tight SLAs, part 1" (''Implantando Diffserv na borda da rede para SLAs apertados)'']
 
  
−
= 20/11: Firewall =
+
<syntaxhighlight lang=text>
 +
[fila-suporte]
 +
musicclass=default
 +
strategy=ringall; roundrobin, rrmemory
 +
timeout=10
 +
wrapuptime=30
 +
periodic-announce = em-breve
 +
periodic-announce-frequency=60
 +
member=>SIP/6111
 +
member=>SIP/6112
 +
</syntaxhighlight>
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-08.pdf Transparências]
+
No plano de discagem a fila de atendimento pode ser usada da seguinte forma:
  
−
* Projetos de firewalls (ver transparências)
+
<syntaxhighlight lang=text>
−
** Estratégias de implantação de firewalls
+
[suporte]
−
** Perímetro de segurança
+
exten=> s,1,Set(CHANNEL(musicclass)=suporte)
−
** Tradução de endereços (NAT) - [http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html Anatomia de Tradutores NAT]
+
exten=> s,2,Playback(bem-vindo)
 +
exten=> s,3,Queue(fila-suporte)
 +
</syntaxhighlight>
  
−
== Dicas para NAT ==
+
=== [http://www.voip-info.org/wiki/view/Asterisk+callgroups+and+pickupgroups Captura de chamadas] ===
  
−
* Fazendo NAT de todo o tráfego que sai pela interface eth0: <syntaxhighlight lang=bash>
+
A captura possibilita que se puxe uma chamada de um colega no mesmo grupo de
−
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
+
chamadas. Isso evita que se tenha que levantar para atender um telefone do seu vizinho que não para de tocar. A captura pode ser feita discando *8 (isso pode ser alterado no arquivo [http://www.voip-info.org/wiki/view/Asterisk+config+features.conf ''features.conf'']).
−
</syntaxhighlight>
 
−
* Fazendo NAT estático, de forma a associar um determinado IP externo a um IP interno (obs: eth0 é a interface externa): <syntaxhighlight lang=bash>
 
−
iptables -t nat -A POSTROUTING -o eth0 -s IP_interno -j SNAT --to-source IP_externo
 
−
</syntaxhighlight>
 
−
* Redirecionando um pacote para outro IP e/ou port: <syntaxhighlight lang=bash>
 
−
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 2200 -j DNAT --to-destination IP_interno:22
 
−
</syntaxhighlight>
 
  
−
== Ativando e desativando as regras do filtro IP (iptables) ==
 
  
−
O seguinte script, que deve ser salvo com o nome ''firewall.sh'', pode ser usado para ativar e desativar as regras do filtro IP:
 
  
−
<syntaxhighlight lang=bash>
+
[[imagem:Call-capture.png|400px]]
−
#!/bin/bash
+
<br>''Captura de chamadas - figura obtida de: Flávio Gonçalves. Guia de Configuração para Asterisk PBX, 5a edição.''
−
# Variaveis
 
−
DEV_LAN=eth0
 
−
DEV_WAN=eth1
 
  
−
fw_start(){
+
Para habilitar a captura de chamadas é suficiente definir a que grupo de chamadas cada canal pertence (parâmetro ''callgroup''), e de que grupos se pode capturar chamadas (parâmetro ''pickupgroup''). No caso de canais SIP isso fica em ''sip.conf'':
−
  # Adicionando regras
+
 
−
  iptables -A INPUT -i $DEV_LAN -j ACCEPT
+
<syntaxhighlight lang=text>
−
}
+
[joaozinho]
 +
callgroup=1
 +
pickupgroup=1,2
 +
...
 +
</syntaxhighlight>
  
−
fw_stop(){
+
=== [http://www.voip-info.org/wiki/view/Asterisk+call+parking Estacionamento de chamadas] ===
−
  # Limpando as regras
 
−
  iptables -P INPUT ACCEPT
 
−
  iptables -t filter -F
 
−
}
 
  
−
fw_uso(){
+
O estacionamento de chamadas é feito no arquivo ''features.conf'' fazendo uso dos seguintes parâmetros:
−
  # Mensagem de ajuda
+
* '''parktext''': Extensão utilizada para fazer o estacionamento de chamadas, após invocá-la o sistema irá indicar em qual posição a chamada atual foi estacionada.
−
  echo "Sintaxe errada..."
+
*ˆ '''parkpos''': Define o número de vagas para o estacionamento de chamadas.
−
  echo "./$0 (start|stop)"
+
* '''context''': Define o nome do contexto para o estacionamento de chamadas. É necessário incluir este contexto nos demais contextos que poderão usar o estacionamento de chamadas.
−
}
+
* '''parkingtime''': Se definida, indica o tempo máximo que uma chamada poderá ficar estacionada. Se este tempo estourar o sistema irá fazer uma ligação para o ramal que estacionou a chamada em questão.
  
−
case $1 in
 
−
  start)
 
−
    fw_start
 
−
    ;;
 
−
  stop)
 
−
    fw_stop
 
−
    ;;
 
−
  *)
 
−
    fw_uso
 
−
    ;;
 
−
esac
 
−
</syntaxhighlight>
 
  
−
* Iniciando o firewall: <syntaxhighlight lang=bash>
+
[[imagem:Parking-calls.png]]
−
./firewall.sh start
+
<br>''Estacionamento de chamadas - figura obtida de: Flávio Gonçalves. Guia de Configuração para Asterisk PBX, 5a edição.''
−
</syntaxhighlight>
 
−
* Parando o firewall: <syntaxhighlight lang=bash>
 
−
./firewall.sh stop
 
−
</syntaxhighlight>
 
−
* Obtendo informações sobre seu uso: <syntaxhighlight lang=bash>
 
−
./firewall.sh
 
−
</syntaxhighlight>
 
  
−
== Atividade 1: firewall/roteador para rede doméstica ==
+
Abaixo se pode ver um exemplo de plano de discagem que usa estacionamento de chamadas:
  
−
Uma pequena rede possui um firewall com algumas regras básicas para protegê-la do mundo externo:
+
<syntaxhighlight lang=text>
−
* Política padrão: '''negar tudo''' (entrada e roteamento)
+
[vendas]
−
* Usuários da rede local só podem navegar na web, acessar email (POP3, IMAP, SMTP)
 
−
* Firewall pode ser administrado remotamente via SSH, não importando a origem da conexão.
 
−
** Para dificultar ataques por varredura de portas, o servidor SSH deve atender conexões em uma porta diferente da 22.
 
−
* Registrar todas conexões oriundas da rede externa
 
  
−
== Atividade 2: serviço SMTP rodando em rede com NAT ==
+
include=>parkedcalls
  
−
[[imagem:Fw-lab3.png]]
+
exten=>6200,1,Dial(SIP/6200,30,tT)
 +
exten=>6200,n,Hangup
 +
</syntaxhighlight>
  
 +
== Atividade ==
  
−
* Política padrão: '''negar tudo''' (entrada e roteamento)
+
Nesta aula faremos experimentos usando ATA, Telefone IP e softphones junto com o Asterisk. Em seguida, testaremos algumas das funções de PBX apresentadas hoje.
−
* Permitir pings a uma taxa máxima de 10 pacotes por minuto
 
−
* Tráfego destinado à porta 25 deve ser encaminhado para a porta 25 do computador M1 da rede local
 
−
** Isso se destina impedir que máquinas da rede local gerem SPAM através de conexões diretas a servidores SMTP externos
 
−
* Tanto o firewall quanto a máquina M1 podem ser administradas remotamente via SSH.
 
  
−
Obs: para monitorar quantos pacotes estão casando com as regras:
+
# Instale um ATA ou telefone IP, fazendo com que se registre via SIP em seu Asterisk. Teste-o realizando chamadas para um softphone, e vice-versa.
−
<syntaxhighlight lang=bash>
+
# Crie uma fila de atendimento com dois membros e música de espera.
−
watch iptables -t filter -L -v
+
# Crie um serviço de estacionamento de chamadas. Para testá-lo serão necessários ao menos três telefones (os dois que estabelecem originalmente a chamada, e um terceiro para capturar uma chamada estacionada).
−
</syntaxhighlight>
 
  
−
Obs: para limitar a taxa de pacotes deve-se usar o módulo ''limit'' (ver maiores detalhes no [http://manpages.ubuntu.com/manpages/natty/man8/iptables.8.html manual]). Por exemplo:
+
= 13/11: Asterisk: URA, STUN e integração com DNS =
−
<syntaxhighlight lang=bash>
 
−
# limita as cconexões ao servidor web: no máximo 2 por segundo
 
−
iptables -A FORWARD -p tcp -m limit -m multiport -m state -d IP_servidor_web --dports 80,443
 
−
--state NEW --limit-rate 2/second -j ACCEPT
 
−
</syntaxhighlight>
 
  
−
{{collapse top | Exemplo de regras}}
+
== URA ==
−
<syntaxhighlight lang=bash>
 
−
#!/bin/bash
 
−
# Variaveis
 
−
DEV_LAN=eth1
 
−
DEV_WAN=eth0
 
−
SMTP_SERVER=192.168.2.1
 
−
PC=10.1.1.1
 
−
 
−
fw_start(){
 
−
  # Adicionando regras
 
−
  iptables -P INPUT DROP
 
−
  iptables -P FORWARD DROP
 
−
 
 
−
  # Libera fluxos estabelecidos
 
−
  iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
 
  
−
  iptables -A FORWARD -i $DEV_LAN -p icmp -m limit --limit 10/min -j ACCEPT
+
O que é uma URA (''Unidade de Resposta Audível'') ? Clique na imagem abaixo ...
−
  iptables -A FORWARD -i $DEV_LAN -m state --state NEW,RELATED -j ACCEPT
 
  
−
  iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
+
[[imagem:Ura-tabajara.png|link=http://www.youtube.com/watch?v=VfDh2GhGnVg]]
−
  iptables -A INPUT -i $DEV_WAN -p tcp --dport 22 -m state --state NEW -j ACCEPT
+
<br>''URA Tabajara''
−
  iptables -A INPUT -i $DEV_LAN -p tcp --dport 3128 -m state --state NEW -j ACCEPT
 
−
  iptables -A INPUT -i $DEV_LAN -p tcp --dport 22 -m state --state NEW -j ACCEPT
 
  
−
  #NAT
+
Uma URA implementa um menu audível para auto-atendimento. Sua construção é feita toda no plano de discagem, como se pode ver no exemplo abaixo:
−
  iptables -t nat -A POSTROUTING -o $DEV_WAN -j MASQUERADE
 
−
  iptables -t nat -A PREROUTING -i $DEV_LAN -p tcp --dport 25 -j DNAT --to-destination $SMTP_SERVER
 
−
  iptables -t nat -A PREROUTING -i $DEV_WAN -p tcp --dport 2200 -j DNAT --to-destination ${PC}:22
 
−
 
 
−
}
 
−
 
−
fw_stop(){
 
−
  # Limpando as regras
 
−
  iptables -P INPUT ACCEPT
 
−
  iptables -P FORWARD ACCEPT
 
−
  iptables -t filter -F
 
−
  iptables -t nat -F
 
−
}
 
−
 
−
fw_uso(){
 
−
  # Mensagem de ajuda
 
−
  echo "Sintaxe errada..."
 
−
  echo "./$0 (start|stop)"
 
−
}
 
−
 
−
case $1 in
 
−
  start)
 
−
    fw_start
 
−
    ;;
 
−
  stop)
 
−
    fw_stop
 
−
    ;;
 
−
  *)
 
−
    fw_uso
 
−
    ;;
 
−
esac
 
−
</syntaxhighlight>
 
−
{{collapse bottom}}
 
  
−
= 22/11: Lista de exercícios: Firewall =
+
<syntaxhighlight lang=text>
 +
[default]
 +
exten => 666,1,Goto(ura,s,1)
  
−
Nesta aula a turma se organizará em grupos, que devem resolver o seguinte problema:
+
[ura]
 +
exten => s,1,Answer
 +
exten => s,2,NoOp(Ligação entrou na URA)
 +
exten => s,n,Background(/var/lib/asterisk/sounds/benvindo)
 +
exten => s,n,NoOp(Digite a opção/1-suporte/2-comercial/3-financeiro)
 +
exten => s,n,WaitExten(6); caso nada tenha sido digitado durante a mensagem "benvindo", espera mais 6 segundos no máximo
  
−
[[imagem:Fw-lista1.png]]
+
exten => 1,1,NoOp(Chamada foi para Suporte)
 +
same => n,Dial(SIP/2402,60)
 +
same => n, Hangup
  
 +
exten => 2,1,NoOp(Chamada foi para Comercial)
 +
same => n,Dial(SIP/2801,60)
 +
same => n, Hangup
  
−
A rede acima é composta de dois segmentos, ambos implantados com subredes IP com endereços não roteáveis:
+
exten => 3,1,NoOp(Chamada foi para Financeiro)
−
* '''DMZ:''' contém servidores que podem sere acessados a partir da rede externa.
+
same => n,Dial(SIP/2000,60)
−
* '''Rede interna:''' contém computadores que não podem ser acessados de fora.
+
same => n, Hangup
  
−
Crie as regras do filtro IP no firewall para que os serviços indicados nos servidores da DMZ possam ser acessados de fora. Essas regras devem também permitir o acesso irrestrito dos computadores da rede interna à Internet (ex: o Pc). Os servidores da DMZ, por sua vez, não podem iniciar conexões - seja para a rede interna ou externa. Além disso, o firewall deve poder ser administrado remotamente via SSH. Por fim, devem ser registrados todos os inícios de conexões e todos os pacotes recusados.
+
exten => i,1,NoOp(Extensão inválida)
 +
same => n,Play(beep)
 +
same => n,GoTo(s,3); volta para o menu
  
−
Obs: quem quiser fazer o exercício com o [[Netkit]] pode usar o seguinte modelo para a rede:
+
exten => t,1,NoOp(Tempo esgotado)
−
 
+
same => n,Dial(SIP/3401,60)
−
<syntaxhighlight lang=text>
+
same => n,Hangup
−
global[compact]=1
 
−
dmz1[type]=generic
 
−
dmz2[type]=generic
 
−
pc[type]=generic
 
−
firewall[type]=gateway
 
−
 
−
# Um computador pode ser usado para representar a Internet (!?!)
 
−
internet[type]=generic
 
−
 
−
dmz1[eth0]=dmz:ip=10.0.0.1/24
 
−
dmz2[eth0]=dmz:ip=10.0.0.2/24
 
−
firewall[eth1]=dmz:ip=10.0.0.254/24
 
−
 
−
pc[eth0]=lan-interna:ip=192.168.0.1/24
 
−
firewall[eth2]=lan-interna:ip=192.168.0.254/24
 
−
 
−
firewall[eth0]=link-internet:ip=172.18.0.100/16
 
−
 
−
# A "Internet" tem só o IP 172.18.0.1 ;-)
 
−
internet[eth0]=link-internet:ip=172.18.0.1/16
 
−
 
−
dmz1[default_gateway]=10.0.0.254
 
−
dmz2[default_gateway]=10.0.0.254
 
−
 
−
pc[default_gateway]=192.168.0.254
 
−
 
 
−
# Se o script firewall.sh ficar em /root, ele pode ser preservado para poder ser usado
 
−
# em proximas execucoes da rede virtual. Porém para isso deve-se exportar
 
−
firewall[preserve]=/root/firewall.sh
 
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
== Documento a ser entregue ==
+
A URA é composta por mensagens de voz, que instruem o usuário sobre o que ele pode fazer (isto é, apresentam as opções), e músicas, que o entreteem (!?) enquanto aguarda uma operação ser realizada. Assim, para criar uma URA minimamente funcional são necessários esses arquivos de voz. Para gravá-los, pode-se criar uma extensão especial que atenda por ''9005nome_de_um_arquivo''. Ao chamar essa estensão, pode-se pronunciar a mensagem de voz assim que o Asterisk atender. Para encerrar a mensagem, deve-se digitar ''#''. O arquivo de voz resultante estará no diretório ''/var/lib/asterisk/sounds'', ou em qualquer outro diretório especificado na aplicação ''record''.
  
−
Apresentar um shell script (comentado) com as funções ''start'', ''stop'', ''restart'' e ''uso'' com as devidas regras para implementação do firewall e roteador. Faça uso de variáveis para os endereços IP, endereços de rede, interfaces de rede, etc. visando assim tornar o script mais genérico.
+
<syntaxhighlight lang=text>
 +
exten=_9005.,1,answer()
 +
exten=_9005.,n,record(/var/lib/asterisk/sounds/${EXTEN:4}.wav,5,t)
 +
exten=_9005.,n,playback(/var/lib/asterisk/sounds/${EXTEN:4})
 +
exten=_9005.,n,hangup()
 +
</syntaxhighlight>
  
−
== Lista de exercícios ==
+
== Atividade ==
  
−
Resolver os exercícios e problemas propostos no capítulo 7 do livro ''Redes de Computadores e a Internet, 5a edição'', de James Kurose. Em particular, resolver:
+
# Crie a URA Tabajara, conforme o vídeo visto na aula.
−
* '''Exercícios de fixação:''' todos
+
# Crie uma URA que possibilite um usuário SIP mudar sua senha. Dica: veja as aplicações [http://www.voip-info.org/wiki/view/Asterisk+cmd+read Read] e [http://www.voip-info.org/wiki/view/Asterisk+cmd+System System] e a função [http://www.voip-info.org/wiki/view/Asterisk+func+shell SHELL].
−
* '''Problemas:''' 1, 3, 4, 5, 7, 9, 10, 11, 20, 21, 22, 23, 24, 25, 26, 27, 28
 
  
−
= 27/11: Lista de exercícios sobre firewall (continuação) =
+
== Implantação de uma infraestrutura VoIP ==
  
−
Concluir a resolução da lista.
+
A implantação de uma infraestrutura VoIP, com  telefones IP ou softphones que possam se comunicar através da Internet, deve atentar para alguns detalhes:
 +
* '''NAT:''' tornou-se prática usual implantar redes usando blocos de endereços privativos e um gateway NAT para interligá-la com a Internet. Isso impõe uma dificuldade para conversações VoIP que seguem o modelo SIP.
 +
* '''Localização:''' a realização de uma chamada entre dois usuários VoIP é trivial se ambos estiverem registrados no mesmo servidor de registro SIP (ex: no mesmo servidor Asterisk), ou se o PBX IP possuir regras em seu plano de discagem para encontrar o usuário chamado. Mas algo mais é necessário se os usuários estiverem registrados em diferentes servidores de registro, e não houver regras de plano de discagem para localizá-los. Isso guarda semelhanças com correio eletrônico.
  
−
== Estendendo as regras do firewall ==
+
Hoje faremos uma discussão sobre algumas técnicas que podem ajudar a resolver esses problemas.
  
−
Na rede do exercício sobre firewall, algumas novas regras de policiamento de tráfego devem ser implantadas:
+
=== STUN: Session Traversal Utilities for NAT ===
−
* '''DMZ:'''
 
−
** O servidor SMTP deve poder enviar mensagens para fora.
 
−
** O servidor WWW pode ser acessado via FTP. As portas a serem usadas no modo passivo vão de 30000 a 30200.
 
−
* '''Rede interna:'''
 
−
** Acesso a web deve ser feito obrigatoriamente por meio de um proxy que roda no firewall. Esse proxy atende na porta TCP 3128.
 
−
** Envio de email somente pode ser feito por meio do servidor SMTP que está na DMZ.
 
−
** Programas de chat devem ser bloqueados (ex: MSN, Jabber, Skype).
 
  
−
= 29/11: QoS em um roteador Linux =
+
* [http://tools.ietf.org/html/rfc5389 RFC 5389]
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-13.pdf Transparências]
 
−
* [http://opalsoft.net/qos/DS.htm Um bom tutorial sobre disciplinas de filas no Linux]
 
−
* [http://lartc.org/howto/ Linux Advanced Routing and Traffic Control Howto:] quase tudo sobre disciplinas de filas (e mais outras coisas).
 
  
−
== Disciplinas de filas (''qdisc'') ==
+
'''''Ou: um quebra-galho para resolver os problemas de outro quebra-galho ...'''''
  
−
Disciplinas de filas são mecanismos para condicionar a saída de pacotes por uma interface de rede. Com elas se podem priorizar pacotes e limitar taxas de bits de fluxos de saída.
 
  
−
[[imagem:Rmu-Qdisc-overview.png|800px]]
+
O estabelecimento de uma chamada VoIP implica iniciar e manter duas streams de áudio (uma em cada sentido da comunicação). Cada stream usa o protocolo RTP, cujas PDUs são transportadas dentro de datagramas UDP. Portanto, cada telefone IP precisa alocar um port UDP, por onde serão recebidas as PDUs RTP.
−
<br>''Visão geral do enfileiramento de pacotes em uma interface de saída''
 
  
−
As filas contidas nas ''qdisc'' podem ser tratadas de diferentes formas. Isso vai determinar a ordem e o ritmo com que os pacotes são desenfileirados para serem transmitidos. Alguns exemplos de ''qdisc'' implementadas no Linux:
+
[[imagem:Voip-call.png|600px]]
−
* '''FIFO:''' pacotes saem por ordem de chegada.
+
<br>''Diagrama que mostra uma chamada VoIP típica intermediada por um PBX. A sinalização se faz através do PBX, mas as streams de áudio RTP são estabelecidas diretamente entre os telefones VoIP.''
−
* '''PRIO:''' pacotes saem de acordo com prioridades.
 
−
* '''SFQ (Stochastic Fair Queueing):''' pacotes saem de forma que os fluxos a que pertencem recebam aproximadamente a mesma taxa de bits.
 
−
* '''TBF (Token Bucket Filter):''' pacotes saem limitados a uma certa taxa de bits.
 
−
* ... e outras (ver [http://opalsoft.net/qos/DS.htm Differentiated Service on Linux HOWTO] e [http://lartc.org/howto/ Linux Advanced Routing and Traffic Control Howto])
 
  
−
Os diagramas abaixo ilustram algumas dessas ''qdisc'':
 
  
−
[[imagem:Rmu-Prio-qdisc.gif|600px]]
+
As informações necessárias para transmitir as PDUs da stream RTP são informadas no momento em que se inicia a chamada. Um dos telefones IP usa o protocolo SIP para solicitar uma chamada com outro telefone (mensagem INVITE). Dentro dessa mensagem INVITE é encapsulada uma mensagem SDP, que contém as informações necessárias para criar uma stream de áudio, tais como codecs aceitos, e endereço IP e port UDP onde o telefone iniciador da chamada espera receber as PDUs RTP. Se o telefone chamado aceitar a chamada, sua resposta SIP terá status ''200 OK'', e encapsulará uma mensagem SDP contendo a identificação dos codecs que aceita utilizar, além de seu endereço IP e port UDP onde espera receber as PDUs RTP. Assim, com base nas informações contidas nas mensagens SDP, os telefones IP podem estabelecer as streams de áudio em ambas direções. A figura abaixo ilustra uma mensagem SDP encapsulada em uma mensagem SIP INVITE.
−
<br>''Uma disciplina de filas baseada em prioridades. Fonte: [http://opalsoft.net/qos/DS.htm Differentiated Service on Linux HOWTO]''
 
  
  
−
[[imagem:Rmu-Tbf-qdisc.gif|400px]]
+
[[imagem:Sdp.png|800px]]
−
<br>''A qdisc TBF (combinada com PRIO), usada para limitar a taxa de saída. Fonte: [http://opalsoft.net/qos/DS.htm Differentiated Service on Linux HOWTO]''
+
<br>''O endereço IP e o port UDP para estabelecer a stream RTP são informados dentro da mensagem SDP, quando o telefone VoIP tenta iniciar uma chamada com SIP (mensagem INVITE). A lista de codecs da mensagem SDP foi omitida por simplicidade.''
 +
 
  
 +
Mas como essas streams de áudio podem ser estabelecidas se existir um ou mais gateways NAT entre os telefones VoIP ? A mensagem SDP com a descrição dos dados de uma stream é preenchida usando o endereço IP e port UDP do telefone VoIP. No entanto, a existência de um gateway NAT faz com que o endereço IP e port UDP desse telefone VoIP sejam diferentes para quem estiver fora de sua rede. O correto seria ter na mensagem SDP o endereço IP e port UDP que serão usados após passar o NAT - quer dizer, os valores que serão visíveis para o outro telefone VoIP. Para isso foi criado o serviço STUN (''Session Traversal Utilities for NAT''), que possibilita que um telefone VoIP (ou qualquer outro cliente) descubra seu endereço IP e port UDP visíveis para quem estiver do outro lado do gateway NAT. A figura abaixo ilustra como o STUN poderia ser usado para essa finalidade.
  
−
[[imagem:Rmu-Dsmark.gif|400px]]
+
[[imagem:STUN.png|600px]]
−
<br>''A qdisc DSMARK, usada em uma estrutura Diffserv com Linux. Fonte: [http://opalsoft.net/qos/DS.htm Differentiated Service on Linux HOWTO]''
+
<br>''Cenário em que se poderia usar STUN''
  
−
== Atividade ==
 
  
−
Para realizar os exercícios abaixo, deve-se criar uma rede composta por um roteador e um computador.
+
O STUN foi criado para ser usado imediatamente antes de iniciar uma transmissão UDP. Como mostrado na figura abaixo, um cliente envia a um servidor STUN uma mensagem de pedido de vinculação (''binding request''), que deve usar como port UDP de origem o mesmo port que se pretende usar para a stream de áudio. Esse servidor STUN deve estar fora da rede, de forma que o pedido de vinculação por ele recebido seja modificado pelo NAT. A resposta do servidor STUN (''binding response'') contém o endereço IP e número de port UDP que apareceram no pedido de vinculação. Com isso o cliente consegue descobrir como esses valores deverão aparecer após passarem pelo NAT. Assim, a mensagem SDP pode ser preenchida com os valores apropriados para a stream de áudio.
  
−
1) Em uma rede deseja-se que os fluxos de entrada (que vem de fora da rede) sejam balanceados. Isso significa que nenhum dos fluxos deve poder monopolizar o link de saída dessa rede. Usando o utilitário '''tc''' implemente esse condicionamento de tráfego no seu roteador Linux. <syntaxhighlight lang=bash>
 
−
# Cria uma qdisc SFQ, que balanceia os fluxos estatisticamente
 
−
# OBS: assume-se que a interface de saída seja eth0
 
−
tc qdisc add dev eth0 root handle 1:0 sfq
 
−
</syntaxhighlight>
 
  
−
2) Nessa mesma rede, deseja-se modificar o condicionamento de tráfego para que fluxos vindos da rede 172.18.0.0/16 sejam priorizados. Implemente essa modificação no seu roteador. <syntaxhighlight lang=bash>
+
[[imagem:Stun-diagram.png|600px]]
−
# Cria uma qdisc PRIO, que usa três filas (bandas) para priorizar fluxos.
+
<br>''Exemplo de mensagens trocadas com STUN''
−
# -- a fila mais prioritária tem handle 1:1
 
−
# -- a próxima fila tem handle 1:2
 
−
# -- a fila menos prioritária tem handle 1:3
 
−
# OBS: assume-se que a interface de saída seja eth0
 
−
tc qdisc add dev eth0 root handle 1:0 prio
 
  
−
# Datagramas vindos da rede 172.18.0.0/16 vão pra fila mais prioritária.
 
−
tc filter add dev eth0 parent 1: prio 1 protocol ip u32 match ip src 172.18.0.0/16 flowid 1:1
 
  
−
# Demais datagramas vão para a fila intermediária.
+
'''Deve-se notar que o STUN não faz milagre !''' Como apontado no início do texto, STUN é um quebra-galho criado para tentar resolver os problemas de outro quebra-galho (no caso, o NAT). Para que o STUN funcione, o NAT deve permitir que datagramas UDP vindos de outro endereço IP (o telefone VoIP na outra ponta da ligação) acessem o endereço IP e port UDP que foram alocados quando da consulta do cliente para o servidor STUN. Como será visto em uma [[RMU-2012-1#11.2F04:_Firewall|aula futura]], isso só é possível se o NAT for do tipo [http://en.wikipedia.org/wiki/Full_cone_NAT ''full cone''], [http://en.wikipedia.org/wiki/Restricted_cone_NAT ''restricted cone''] ou [http://en.wikipedia.org/wiki/Port_restricted_cone_NAT ''port restricted cone'']. Quer dizer, se o NAT for do tipo [http://en.wikipedia.org/wiki/Symmetric_NAT simétrico], o STUN não funcionará. E muitos NAT em equipamentos proprietários são do tipo simétrico (ao contrário do Linux, que implementa um NAT ''port restricted cone'') ...
−
tc filter add dev eth0 parent 1: prio 2 protocol ip u32 match ip src 0.0.0.0/0 flowid 1:2
 
−
</syntaxhighlight>
 
  
−
3) Configure seu roteador de forma a combinar a priorização de fluxos e o balanceamento entre eles.<syntaxhighlight lang=bash>
+
==== NAT e Asterisk ====
−
# Cria uma qdisc PRIO, que usa três filas (bandas) para priorizar fluxos.
 
−
# -- a fila mais prioritária tem handle 1:1
 
−
# -- a próxima fila tem handle 1:2
 
−
# -- a fila menos prioritária tem handle 1:3
 
−
# OBS: assume-se que a interface de saída seja eth0
 
−
tc qdisc add dev eth0 root handle 1:0 prio
 
  
−
# Balanceia os fluxos nas duas filas da qdisc PRIO que serão usadas
+
* [http://www.smartvox.co.uk/astfaq_configbehindnat.htm Dicas sobre Asterisk + NAT]
−
tc qdisc add dev eth0 parent 1:1 handle 2:0 sfq
 
−
tc qdisc add dev eth0 parent 1:2 handle 3:0 sfq
 
  
−
# Datagramas vindos da rede 172.18.0.0/16 vão pra fila mais prioritária.
+
O Asterisk pode ajudar a viabilizar a comunicação com telefones VoIP que estão atrás de gateways NAT. Na definição de cada canal SIP devem-se incluir as opções:
−
tc filter add dev eth0 parent 1: prio 1 protocol ip u32 match ip src 172.18.0.0/16 flowid 1:1
 
  
−
# Demais datagramas vão para a fila intermediária.
+
<syntaxhighlight lang=text>
−
tc filter add dev eth0 parent 1: prio 2 protocol ip u32 match ip src 0.0.0.0/0 flowid 1:2
+
nat=yes
 +
qualify=yes
 +
directmedia=no
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
4) Nessa rede, decidiu-se que fluxos vindos da rede 172.18.0.0/16 devem ter garantidos para si 70 % da capacidade do link, sendo o restante usado para os demais fluxos. Além disso, os fluxos devem estar balanceados. Implemente esse condicionamento de tráfego no seu roteador.
+
[http://www.voip-info.org/wiki/view/Asterisk+sip+nat Aqui] tem uma boa explicação sobre o que fazem essas opções.
  
−
5) O utilitário [http://lartc.org/wondershaper/ wondershaper] se propõe a facilitar a limitação das taxas de download e upload. Experimente utilizá-lo, e confira como ele usa ''qdisc'' para fazer isso.
+
Se for o Asterisk que está atrás de NAT, então deve-se configurar seu IP válido, de forma que o PBX possa informá-lo nas mensagens SDP para as streams de audio. Para isso, deve-se acrescentar em sip.conf:
  
−
== TAREFA: leitura da semana ==
+
<syntaxhighlight lang=text>
 +
[general]
 +
externip=IP_público
 +
; ou:
 +
;externhost=fqdn
  
−
O texto a seguir continua a leitura desta semana, tratando da implantação de uma estrutura Diffserv na borda da rede.
+
; devem-se informar as redes privativas onde está o Asterisk (pode haver mais de uma ... basta repetir o
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/docs/diffserv-network-edge-2.pdf "Deploying Diffserv at the Network Edge for Tight SLAs, part 2" (''Implantando Diffserv na borda da rede para SLAs apertados)'']
+
; atributo localnet para cada subrede). Isso é importante para que o Asterisk saiba quando usar o IP
 +
; público (para telefones fora de sua rede) ou privativo (telefones dentro de sua rede) nas mensagens
 +
; SDP que especificam o IP e port UDP para as streams RTP.
 +
localnet=prefixo/máscara
 +
</syntaxhighlight>
  
−
= 04/12: QoS em roteador Linux =
 
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-13.pdf Transparências]
+
'''OBS:''' isso só funciona quando o Asterisk está no caminho da stream de áudio. No caso de telefones VoIP que conversam diretamente, só resta STUN ou alguma outra técnica do tipo ...
−
* [http://opalsoft.net/qos/DS.htm Um bom tutorial sobre disciplinas de filas no Linux]
 
−
* [http://lartc.org/howto/ Linux Advanced Routing and Traffic Control Howto:] quase tudo sobre disciplinas de filas (e mais outras coisas).
 
−
* [http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm HTB (Hierarchical Token Bucket) queuing discipline ]
 
  
−
== ''qdisc'' com estado (''stateful'') ==
+
==== Servidores STUN ====
  
−
Com exceção da qdisc PRIO, até o momento foram vistas somente qdisc capazes de conter uma única classe. Regras de priorização e condicionamento de tráfego mais elaboradas precisam, no entanto, combinar ''qdisc'' hierarquicamente. Isso pode ser percebido com um primeiro exemplo.
+
Existe uma implementação de um [http://www.vovida.org/applications/downloads/stun/ servidor STUN para Linux] (disponível no Ubuntu via apt). Basta instalá-lo em um computador e usá-lo como servidor STUN, contanto que ele esteja ''do outro lado'' do NAT. No entanto, existem inúmeros servidores STUN públicos, conforme mostrado na listagem abaixo:
−
 
 
−
Em um enlace, deseja-se limitar em 100 kbps o tráfego de um conjunto de aplicações. No entanto, cada aplicação também deve ter um limite de uso do enlace, de acordo com o descrito a seguir:
 
−
* '''WWW (http e https):''' 40 kbps
 
−
* '''SSH:''' 40 kbps
 
−
* '''Demais aplicações:''' 20 kbps
 
−
 
 
−
 
 
−
O diagrama abaixo mostra como poderia ser modelada a limitação de banda para essas aplicações:
 
  
 +
<syntaxhighlight lang=text>
 +
provserver.televolution.net
 +
sip1.lakedestiny.cordiaip.com
 +
stun1.voiceeclipse.net
 +
stun01.sipphone.com
 +
stun.callwithus.com
 +
stun.counterpath.net
 +
stun.endigovoip.com
 +
stun.ekiga.net (alias for stun01.sipphone.com)
 +
stun.ideasip.com (no XOR_MAPPED_ADDRESS support)
 +
stun.internetcalls.com
 +
stun.ipns.com
 +
stun.noc.ams-ix.net
 +
stun.phonepower.com
 +
stun.phoneserve.com
 +
stun.rnktel.com
 +
stun.softjoys.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
 +
stunserver.org see their usage policy
 +
stun.sipgate.net
 +
stun.sipgate.net:10000
 +
stun.voip.aebc.com
 +
stun.voipbuster.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
 +
stun.voxalot.com
 +
stun.voxgratia.org (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
 +
stun.xten.com
 +
numb.viagenie.ca (http://numb.viagenie.ca) (XOR_MAPPED_ADDRESS only with rfc3489bis magic number in transaction ID)
 +
stun.ipshka.com inside UA-IX zone russsian explanation at http://www.ipshka.com/main/help/hlp_stun.php
 +
</syntaxhighlight>
 +
 +
[http://www.voip-info.org/wiki/view/STUN Maiores detalhes sobre servidores STUN]
  
−
[[imagem:Qdisc-ex1.png]]
+
=== Integração com DNS ===
  
 +
* [http://www.cisco.com/en/US/docs/voice_ip_comm/sip/proxies/2.1/administration/guide/ddns.html Uma boa explicação no site da Cisco]
  
−
Como isso poderia ser feito usando o ''tc'' ? Usando apenas as ''qdisc'' que já vimos não parece possível implementar essa regras (na dúvida, você pode tentar). Mas se for usada uma ''qdisc'' capaz de conter várias classes, isso poderia ser realizado. Essa ''qdisc'' limitaria o uso de banda a 100 kbps, e dentro dela existiriam três classes (uma para cada tipo de aplicação). Cada classe, por sua vez, conteria uma ''qdisc'' que poderia impor sua limitação de banda específica. E é exatamente isso que a ''qdisc'' [http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm HTB (Hierarchical Token Bucket)] é capaz de fazer, criando uma hierarquia de classes e ''qdisc'' como mostrado na figura abaixo:
+
Uma rede representada por um determinado domínio DNS pode ter seu próprio servidor SIP. Seria conveniente que o endereço desse servidor pudesse ser obtido com uma mera consulta DNS. Isso se assemelha ao caso do correio eletrônico, em que o endereço do MTA de um domínio pode ser descoberto consultando-se seu registro MX. De fato, existe uma forma de descobrir o servidor SIP associado a um domínio DNS. Para isso, deve-se explorar o uso de registros DNS do tipo SRV.
  
 +
Um registro SRV, cuja definição se encontra na [http://tools.ietf.org/html/rfc2782 RFC 2782], possibilita descobrir o nome DNS e o port (TCP ou UDP) de um servidor que responde por um determinado serviço. No caso do SIP de um domínio, o registro SRV deve ser especificado da seguinte forma:
  
−
[[imagem:Qdisc-ex1-diagram.png]]
+
_sip._udp SRV 0 5060 nome.do.servidor.sip.
  
 +
... sendo ''0'' a prioridade desse servidor (positivo, e quanto menor, maior a prioridade), 5060 o port onde ele atende requisições, e ''nome.do.servidor.sip'' seu nome DNS.
  
−
<syntaxhighlight lang=bash>
+
O próprio serviço STUN pode ser obtido usando registros SRV, mas isso depende do telefone VoIP (ou do PBX, caso ele esteja fazendo papel de participante em uma chamada VoIP). Nesse caso, o registro SRV deve ser definido da seguinte forma:
−
# adiciona a qdisc raiz na interface eth0
 
−
tc qdisc add dev eth0 root handle 1:0 htb default 23
 
  
−
# cria a classe filha, que impõe o limite de banda global desta HTB
+
_stun._udp SRV 0 3478 nome.do.servidor.stun.
−
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100kbps ceil 100kbps
 
  
−
# cria as classes das aplicações
+
=== Atividade ===
−
tc class add dev eth0 parent 1:1 classid 1:21 htb rate 40kbps ceil 100kbps
 
−
tc class add dev eth0 parent 1:1 classid 1:22 htb rate 40kbps ceil 100kbps
 
−
tc class add dev eth0 parent 1:1 classid 1:23 htb rate 20kbps ceil 100kbps
 
  
−
# cria os filtros para classificar os datagramas
+
Hoje vamos continuar a [[RMU-2012-2#06.2F11:_Interligando_PBX_Asterisk|atividade da semana passada]], em que se criou uma infraestrutura com múltiplos PBX Asterisk. Vamos incrementá-la implantando as seguintes melhorias:
−
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 80 0xffff flowid 1:21
+
# Execute uma máquina virtual Ubuntu Desktop, mas antes configure sua interface ethernet para operar em modo NAT.
−
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 443 0xffff flowid 1:21
+
# Instale o softphone [http://tele.sj.ifsc.edu.br/~msobral/soft/jitsi_1.0-latest_i386.deb Jitsi] nessa máquina virtual. Configure-o para usar o seu PBX.
−
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 22 0xffff flowid 1:22
+
# Execute o wireshark, e deixe-o capturando datagramas UDP em todas as interfaces de rede.
−
</syntaxhighlight>
+
# Tente realizar uma chamada entre softphone e telefone IP. A chamada foi realizada ? O que mostrou o wireshark ?
 +
# Configure o softphone e o telefone IP para usarem o servidor STUN instalado em 192.168.2.1.
 +
# Tente novamente realizar uma chamada entre softphone e telefone IP. A chamada foi realizada ? O que mostrou o wireshark ?
  
−
A ''qdisc'' HTB funciona da seguinte forma:
+
<!-- # Cada dupla de alunos deve criar um domínio DNS próprio, e que seja subdomínio de ''rmu.sj.ifsc.edu.br''. O nome do subdomínio deve ser informado ao professor, para que seja adicionado ao servidor do domínio ''rmu.sj.ifsc.edu.br''.
−
* Cada classe possui uma taxa garantida e uma taxa máxima.
+
# Em seu subdomínio inclua um registro SRV para apontar seu PBX Asterisk.
−
* A banda garantida não utilizada por uma classe reverte para para sua classe mãe (um nível acima na hierarquia). Essa sobra pode assim ser aproveitada pelas outras classes filhas.
+
-->
−
* Cada classe pode emprestar banda adicional de sua classe mãe até o limite especificado por sua taxa máxima.
 
−
* Se houver mais de uma classe filha requisitando banda adicional, a classe mãe divide essa banda proporcionalmente à taxa garantida de cada filha.
 
−
* Classes podem ter prioridades, de forma que classes mais prioritárias se apropriam primeiro da banda de sobra (mas a taxa garantida é preservada).
 
  
 +
== TAREFA: Leitura da semana ==
  
−
Os parâmetros da qdisc HTB estão sumarizados abaixo:
+
Usando [http://www.opentelecoms.org/federated-voip este ponto de partida] prepare uma apresentação sobre VoIP federada. Você pode se referir também ao serviço [http://www.rnp.br/servicos/voip.html fone@RNP] para ajudar na explicação.
  
−
{| border="1" cellpadding="2"
+
= 20/11: Trabalho Asterisk =
−
!Parâmetro
 
−
!Descrição
 
−
!Exemplo
 
−
|-
 
−
| rate || taxa garantida || rate 100kbit
 
−
|-
 
−
|ceil || taxa máxima || ceil 200 kbit
 
−
|-
 
−
|prio || prioridade da classe (menores valores = maiores prioridades) || prio 1
 
−
|-
 
−
|burst || quantidade máxima de bytes de uma classe, dentro da taxa garantida,<br>que podem ser enviados antes de servir outra classe || burst 20 kb
 
−
|-
 
−
|cburst || quantidade máxima de bytes de uma classe, acima da taxa garabntida,<br>que podem ser enviados antes de servir outra classe || cburst 20 k
 
−
|}
 
  
−
=== Atividade ===
+
Uma empresa possui uma matriz e filiais em outras cidades, cuja rede telefônica atual se baseia em links E1 e troncos analógicos entre os PBX. Uma reestruturação pretende substituir esses links por troncos SIP ou IAX2, a serem estabelecidos através dos links de dados. A nova estrutura será baseada em PBX Asterisk, da qual os links telefônicos convencionais serão removidos.
  
−
{{collapse top | Como configurar o cenário de teste dos exercícios}}
 
  
−
'''Obs:''' para os exercícios abaixo pode ser usado o VirtualBox ou o [[Netkit|gnome-netkit]]. No caso da segunda opção, o seguinte arquivo de configuração cria uma rede composta por um firewall (na verdade, um gateway) e três computadores. O firewall está conectado à rede real por meio de um link em modo NAT.
+
O modelo da rede telefônica em cada unidade da empresa deve se compor de:
 +
* PBX IP Asterisk
 +
* telefones IP, softphones e telefones convencionais
 +
* ao menos um tronco analógico para a PSTN
 +
* um link para Internet
  
−
{| border="0" cellpadding="2"
 
−
|-
 
−
|<syntaxhighlight lang=text>
 
−
pc1[type]=generic
 
−
pc2[type]=generic
 
−
pc3[type]=generic
 
−
fw[type]=gateway
 
  
−
fw[eth0]=link:ip=192.168.0.254/24
+
Nessa nova rede, as chamadas devem ser realizadas da seguinte maneira:
−
fw[eth1]=uplink:ip=10.0.0.1/30
+
* chamadas para números de outras unidades da empresa devem ser encaminhadas diretamente ao PBX correspondente
−
fw[nat]=eth1
+
* chamadas para PSTN devem ser encaminhadas preferencialmente para o PBX mais próximo do número chamado (isso depende do código de área)
−
fw[preserve]=/root/firewall.sh
+
** uma chamada para PSTN deve ser precedida pelo dígito 0 (zero).
 +
** caso isso falhe (ex: linha da filial já esteja em uso), a chamada deve ser feita diretamente pela linha telefônica local.
  
−
pc1[eth0]=link:ip=192.168.0.1/24
+
A Matriz será implantada pelo professor, e cada equipe implantará uma filial.
−
pc1[default_gateway]=192.168.0.254
 
  
−
pc2[eth0]=link:ip=192.168.0.2/24
+
Implante essa estrutura, assumindo que os troncos IAX2 entre PBX das unidades da empresa devam ser autenticado com usuário ''EquipeXX'' e senha ''SenhaXX'' (a matriz tem usuário ''Matriz'' e senha ''Matriz''). Além disso, a estrutura deve atender a estes requisitos:
−
pc2[default_gateway]=192.168.0.254
+
# Os troncos entre PBX das unidades da empresa devem ser IAX2.
 +
# Ramais da empresa possuem quatro dígitos, sendo que o primeiro dígito representa a unidade da empresa (8: Matriz, 1 a 7: filiais). O ramal 9 chama a telefonista, e o prefixo 0 direciona a chamada para a PSTN.
 +
# A telefonista fica na matriz.
 +
# Os ramais em cada unidade da empresa são divididos em: administração e produção. Ramais da produção podem fazer captura de chamadas somente entre si, mas os da administração podem fazer captura de todos os ramais.
 +
# O ramal especial 6XXX dá acesso ao SAC da empresa, que está replicado em cada unidade da empresa. Esse é feito inicialmente por uma URA, que deve oferecer um menu com as seguintes opções:
 +
## Dúvidas sobre produtos, que são encaminhadas ao setor de vendas.
 +
## Clientes corporativos, que são encaminhadas ao setor de marketing.
 +
## Outras necessidades, que são encaminhadas à telefonista.
  
−
pc3[eth0]=link:ip=192.168.0.3/24
+
'''Orientações:'''
−
pc3[default_gateway]=192.168.0.254
+
* O trabalho pode ser feito por equipes de no máximo três alunos.
−
</syntaxhighlight> || [[imagem:Qos-netkit.png]]
+
* A entrega do trabalho deve ser feita até o dia '''27/11'''.  
−
|}
+
* O trabalho deve ser demonstrado dentro do laboratório de Redes 2, estando os membros da equipe sujeitos a questionamentos.
 +
* Deve ser entregue um relatório contendo uma explicação sobre como foram implementadas as características e funcionalidades da estrutura, incluindo as configurações que foram realizadas no Asterisk.
  
−
Para testar as regras, faça downloads usando [http://manpages.ubuntu.com/manpages/gutsy/man1/wget.1.html wget] ou [http://manpages.ubuntu.com/manpages/natty/en/man1/scp.1.html scp] a partir das máquinas virtuais ''pc1'', ''pc2'' e ''pc3''. Use esses programas para transferir arquivos de um servidor externo, ou do próprio firewall, e assim poder observar o efeito das regras de condicionamento de tráfego. Adicionalmente, você pode também executar o [http://manpages.ubuntu.com/manpages/hardy/man8/iptraf.8.html iptraf] no firewall para visualizar as taxas dos diferentes fluxos (escolha o menu ''IP traffic monitor'').  
+
== Tabela de equipes ==
 +
 
 +
{| border="1" cellpadding="2"
 +
!Equipe
 +
!Membros
 +
!Ramais
 +
!IP
 +
!Código de área
 +
|-
 +
|1 || Kalvim, Ana|| 1000 a 1999 || 192.168.2.201 || 41
 +
|-
 +
|2 || Mário,Maicky|| 2000 a 2999 || 192.168.2.202 || 43
 +
|-
 +
|3 || Fabiano, Leandro, Lia|| 3000 a 3999|| 192.168.2.203 || 49
 +
|-
 +
|4 || Emanuel|| 4000 a 4999 || 192.168.2.204 || 47
 +
|-
 +
|5 || André, Luiz Gustavo|| 5000 a 5999 || 192.168.2.205 ||51
 +
|-
 +
|6 || Marine|| 7000 a 7999 || 192.168.2.207 || 55
 +
|-
 +
|Matriz || Professor || 8000 a 8999 || 192.168.2.101 || 48
 +
|}
  
−
Para executar automaticamente os servidores Apache2 e ssh no firewall, acrescente a seguinte linha ao arquivo de configuração da rede:
 
  
−
<syntaxhighlight lang=text>
+
'''OBS:''' para ativar o endereço IP de sua equipe, execute o seguinte comando no sistema hospedeiro:
−
firewall[services]=ssh:apache2
+
<syntaxhighlight lang=bash>
 +
sudo ifconfig eth0 IP_da_sua_equipe
 +
sudo route add default gw 192.168.2.1
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
{{collapse bottom}}
+
== Como criar a rede de desenvolvimento ==
  
−
1) Na rede usada nos exercícios da semana passada, decidiu-se que fluxos vindos das redes 172.18.0.0/16 ou 200.135.37.64/26 devem ter garantidos para si 70 % da capacidade do link, sendo o restante usado para fluxos vindos de outras redes. Além disso, os fluxos devem estar balanceados. Implemente esse condicionamento de tráfego no seu roteador usando a qdisc HTB.
+
A rede de cada unidade da empresa tem uma estrutura como mostrado na seguinte figura:
  
−
2) Modifique as regras de QoS do exercicio 1 para que seja garantido o pleno atendimento de ate 4 streams de audio (VoIP), independente da origem.
+
[[imagem:Trab-asterisk-1.png]]
  
−
3) Um provedor oferece três planos de acesso:
 
−
<br>- ''Ouro:'' taxa garantida de 10 Mbps e taxa de pico ilimitada.
 
−
<br>- ''Prata:'' taxa garantida de 4 Mbps e taxa de pico de 8 Mbps
 
−
<br>- ''Bronze:'' taxa garantida de de 1 Mbps e taxa de pico de 4 Mbps, porém com prioridade reduzida.
 
−
<br>Essas taxas se aplicam a ''downlink''. Para ''uplink'' o provedor fornece metade da taxa de ''downlink''.
 
−
Implemente as regras de QoS do seu roteador, assumindo que o link para Internet tem capacidade de 100 Mbps.
 
  
−
4) A disciplina de filas WFQ, existente em roteadores Cisco e usada para garantir banda para classes de serviço, não está implementada no controle de tráfego do Linux. Com as disciplinas existentes no Linux seria possível emular a WFQ ? Caso sim, como isso poderia ser feito ?
+
Para desenvolver o trabalho, essa rede deve em parte ser feita com máquinas virtuais (VM) Virtualbox. Para fins de simplificação, o PBX e o roteador podem ser implantados na mesma VM. No laboratório, a VM a ser utilizada se chama RMU-Asterisk, que já possui o Asterisk instalado e os demais softwares necessários para usar o módulo EBS Khomp. Existem diferentes formas de configurar essas VM, sendo uma delas a mostrada abaixo:
  
−
== Classificação com iptables ==
 
  
−
Além de filtros criados com o utilitário ''tc'', a classificação de pacotes pode ser feita também com o auxílio do ''iptables''. Isso possibilita que se usem os seletores do filtro IP, os quais oferecem muitas possibilidades de classificação.  
+
[[imagem:Trab-asterisk-2.png]]
  
−
Para fins de classificação, deve-se usar a tabela ''mangle''. Além disso, o uso do ''iptables'' pode ser feito de duas formas:
 
−
# '''Selecionando diretamente a classe de tráfego:''' usando-se o alvo CLASSIFY pode-se definir a classe onde deve ser colocado o pacote: <syntaxhighlight lang=bash>
 
−
# coloca pacotes do SSH na classe 1:21
 
−
iptables -t mangle -A POSTROUTING -p tcp --dport 22 -j CLASSIFY --set-class 1:21
 
−
</syntaxhighlight>
 
−
# '''Marcando os pacotes:''' pode-se marcar os pacotes com o ''iptables'', de forma que a marcação seja usada por um filtro do ''tc'' para concluir a classificação: <syntaxhighlight lang=bash>
 
−
# filtro do tc que classifica de acordo com a marcação: pacotes com marca "2" são colocados na classe 1:21
 
−
tc filter add dev eth0 parent 1:0 protocol ip handle 2 fw flowid 1:21
 
  
−
# iptables marca o pacote
+
# A VM deve ter uma interface de rede em modo NAT (para acesso à rede externa) e outra em modo bridge (para acessar o módulo EBS). A interface em modo bridge deve usar um endereço IP estático com valor 10.0.X.1/24, sendo X o número da equipe. O módulo EBS, ao ser configurado, deve usar um endereço IP 10.0.X.2/24.
−
iptables -t mangle -A FORWARD -i eth0 -p tcp --dport 22 -j MARK --set-mark 2
+
# Na VM faça o seguinte:
−
</syntaxhighlight>
+
## Instale os seguintes softwares com apt-get: openjdk-6-jre libxalan2-java
 +
## Certifique-se de que o conteúdo do arquivo /etc/network/interfaces esteja assim: <syntaxhighlight lang=text>
 +
auto lo eth0
  
−
=== Atividade ===
+
iface lo inet loopback
  
−
Modifique as regras criadas nos [[RMU-2012-1#Atividade_8|exercícios anteriores]] para que usem:
+
iface eth0 inet dhcp
−
# iptables para classificação direta (alvo CLASSIFY)
+
</syntaxhighlight>
−
# iptables para marcar pacotes (alvo MARK)
+
## Após reiniciar a VM, obtenha o [http://tele.sj.ifsc.edu.br/~msobral/soft/jitsi_1.0-latest_i386.deb Jitsi] e instale-o assim: <syntaxhighlight lang=bash>
 +
sudo dpkg -i jitsi_1.0-latest_i386.deb
 +
</syntaxhighlight>
 +
 
 +
== Como criar o tronco IAX2 ==
 +
 
 +
Para criar o tronco IAX2 com os demais PBX, insira a seguinte configuração em /etc/asterisk/iax.conf:
 +
 
 +
<syntaxhighlight lang=text>
 +
; XX: número da sua equipe
 +
; YY: número da equipe do outro PBX
 +
[EquipeXX-YY]
 +
type=friend; pode iniciar e receber chamadas
 +
username=EquipeYY-XX; identidade do asterisk da outra ponta do canal
 +
context=seu_contexto; contexto em que processa chamadas recebidas
 +
callerid="PBX EquipeXX"
 +
secret=SenhaXX; senha para autenticar a chamada (iniciadas e recebidas)
 +
host=IP_do_PBX_YY; endereço IP do asterisk na outra ponta do tronco
 +
peercontext=rmu; contexto que deve processar a chamada no asterisk destino
 +
</syntaxhighlight>
  
−
= 06/12: Resolução de exercícios =
+
No plano de discagem você deve encaminhar chamadas por esse canal IAX2. Por exemplo, se quiser chamar o número 33812850, a aplicação ''Dial'' no plano de discagem deve ser invocada assim:
  
−
... da [[RMU-2012-1#25.2F04:_QoS_em_roteador_Linux|aula anterior]].
+
<syntaxhighlight lang=text>
 +
exten=>33812850,1,Dial(IAX2/EquipeXX-YY/033812850)
 +
</syntaxhighlight>
  
−
= 11/12: Diffserv em roteador Linux =
+
Note que esse exemplo deve ser adaptado no seu plano de discagem para que fique genérico, possibilitando chamar qualquer número da PSTN através desse canal IAX2.
  
−
* [http://datatracker.ietf.org/wg/diffserv/charter/ Página do Grupo de Trabalho DiffServ no IETF]
+
= 22/11: Trabalho 1 =
−
* [http://datatracker.ietf.org/doc/rfc2475/ RFC 2475: Definição da Arquitetura DiffServ]
 
−
* [http://datatracker.ietf.org/doc/rfc3246/?include_text=1 RFC 3246: Comportamento de um PHB Expedited Forwarding (EF)]
 
−
* [http://datatracker.ietf.org/doc/rfc3248/ RFC 3248: Uma Revisão Alternativa com Atraso Limitado para PHB EF]
 
−
* [http://datatracker.ietf.org/doc/rfc2597/ RFC 2597: Comportamento de um PHB Assured Forwarding (AF)]
 
  
−
== Visão geral ==
+
E MCC 2012.
  
−
Uma [[RMU-2012-1#22.2F03:_DiffServ:_Servi.C3.A7os_Diferenciados_na_Internet|visão geral sobre DiffServ]] já foi apresentada no início do semestre. Um domínio DiffServ é composto por rotadores com comportamentos predefinidos (''PHB - Per Host Behavior''), e que policiam e condicionam fluxos de acordo com suas classes. Dentre os quatro grupos de classes, vale destacar estes dois:
+
...
  
−
* '''Encaminhamento Acelerado (Expedited Forwarding - EF):''' proporciona baixo atraso, baixo jitter, baixa perda de pacotes. Uma boa discussão sobre esse PHB pode ser encontrada [http://opalsoft.net/qos/DS-16.htm aqui].
+
= 27/11: Introdução à qualidade de serviço (Qos) =
−
** ''Principal característica:'' definir um limite superior para atraso de encaminhamento em um nodo, assumindo que a fila de saída esteja usualmente vazia ou seja curta.
 
−
** ''Finalidade:'' atender fluxos que necessitam de atrasos e jitter estritos.<br>De acordo com a [http://datatracker.ietf.org/doc/rfc3246/?include_text=1 RFC 3246]: <syntaxhighlight lang=text>
 
−
Intuitively, the definition of EF is simple: the rate at which EF
 
−
traffic is served at a given output interface should be at least the
 
−
configured rate R, over a suitably defined interval, independent of
 
−
the offered load of non-EF traffic to that interface.
 
−
</syntaxhighlight> ... e complementado pela [http://datatracker.ietf.org/doc/rfc3248/?include_text=1 RFC 3248]:<syntaxhighlight lang=text>
 
−
For a traffic stream not exceeding a configured rate the goal of the
 
−
DB PHB is a strict bound on the delay variation of packets through a
 
−
hop.
 
  
−
Traffic MUST be policed and/or shaped at the source edge (for
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-03.pdf Transparências]
−
example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in
+
* [http://www.scribd.com/doc/57127868/Cisco-QoS-Concept-and-Design Cisco QoS Concept and Design]
−
order to get such a bound. However, specific policing and/or shaping
 
−
rules are outside the scope of the DB PHB definition. Such rules
 
−
MUST be defined in any per-domain behaviors (PDBs) composed from the
 
−
DB PHB.
 
−
</syntaxhighlight>
 
−
* '''Encaminhamento Assegurado (Assured Forwarding - AF):''' oferece diferentes probabilidades de que pacotes sejam encaminhados.
 
−
** ''Principal característica:'' a probabilidade de que pacotes sejam encaminhados depende dos recursos alocados (''buffer'' e largura de banda) para cada classe AF e respectivas precedências de descartes em caso de congestionamento.
 
−
** ''Finalidade:'' limitar a vazão de fluxos, respeitando rajadas em certa medida.<br>De acordo com a [http://datatracker.ietf.org/doc/rfc2597/?include_text=1 RFC 2597]:<syntaxhighlight lang=text>
 
−
In a DS node, the level of forwarding assurance of an IP packet thus
 
−
depends on (1) how much forwarding resources has been allocated to
 
−
the AF class that the packet belongs to, (2) what is the current load
 
−
of the AF class, and, in case of congestion within the class, (3)
 
−
what is the drop precedence of the packet.
 
−
</syntaxhighlight>
 
  
−
As outras classes são ''Default PHB'', que corresponde a um serviço melhor esforço, e ''Class Selector PHB'', que se baseia na interpretação convencional do campo ToS do cabeçalho IP.
+
Como medir a qualidade de serviço de uma rede ?
 +
* Disponibilidade ?
 +
* Largura de banda
 +
* Latência (atraso fim-a-fim)
 +
* Variação de atraso (jitter)
 +
* Perda de pacotes
  
−
A implantação de um domínio DiffServ usando roteadores Linux implica usar as regras de controle de tráfego do Linux (via utilitários ''tc'' e ''iptables'') para criar essas classes. Para isso precisamos ter claro o seguinte:
 
−
* Como policiar tráfego que entra em um domínio DiffServ ?
 
−
* Como modificar o campo DSCP de datagramas IP, e como usar o valor desse campo para identificar uma classe de tráfego ?
 
−
* Como limitar atrasos de encaminhamento ?
 
−
* Como garantir banda a um fluxo agregado, com certa tolerância a rajadas ?
 
−
* Como fazer descartes com diferentes probabilidades e precedências ?
 
  
−
== Marcação DiffServ ==
+
[[imagem:Rmu-tabela-qos.png]]
 +
<br>''Um comparativo de requisitos de QoS de algumas aplicações''
 +
 
  
−
No DiffServ, o campo DSCP de datagramas IP é usado para indicar a classe a que pertence cada datagrama. Com base nesse valor, cada roteador pode aplicar seu PHB e assim condicionar o tráfego. Existem duas formas de marcar o campo DSCP e usar esse valor para classificação:
+
* '''Como prover QoS ?'''
−
# '''Usando o ''tc'':''' isso pode ser feito diretamente com o ''tc'', por meio de uma qdisc especial chamada [http://lartc.org/howto/lartc.adv-qdisc.dsmark.html DSMARK] combinada a filtros. Essa forma de marcar e classificar datagramas é um pouco mais complexa, como se pode ver por este exemplo: <syntaxhighlight lang=bash>
 
−
# Cria a qdisc DSMARK com 64 índices.
 
−
tc qdisc add dev eth0 handle 1:0 root dsmark indices 64 set_tc_index
 
  
−
# Cria uma classe DSMARK para definir o valor do DSCP para 0xb8
+
[[imagem:Qos-tarefas.png|600px]]
−
tc class change dev eth0 classid 1:1 dsmark mask 0x3 value 0xb8
 
  
−
</syntaxhighlight>... e para escolher uma classe dependendo do valor DSCP:<syntaxhighlight lang=bash>
 
−
# Filtro que usa o valor do DSCP para calcular o valor do handle de outro filtro. Quer dizer,
 
−
# este filtro serve apenas para selecionar outro filtro.
 
−
tc filter add dev eth0 parent 1:0 protocol ip prio 1 tcindex mask 0xfc  shift 2
 
  
−
# Uma qdisc HTB com taxa de 100 kBps e duas classes .. apenas para exemplificar o uso do filtro tc_index mais abaixo
+
== Uma pequena experiência ==
−
tc qdisc add dev eth0 parent 1:0 handle 2:0 htb default 13
 
−
tc class add dev eth0 parent 2:0 classid 2:1 htb rate 100kbps ceil 100kbps
 
−
tc class add dev eth0 parent 2:1 classid 2:12 htb rate 80kbps ceil 100kbps
 
−
tc class add dev eth0 parent 2:1 classid 2:13 htb rate 20kbps ceil 100kbps
 
  
−
# O filtro ao final selecionado escolhe a classe a receber o pacote. Esse filtro está vinculado a uma qdisc
+
Nessa experiência, todos vão realizar um download simultâneo de um grande arquivo. Enquanto isso, um dos alunos vai visualizar um video via ''streaming''.  
−
# com handle 2:0, e se ativado classifica o datagrama na classe 2:12. O handle do filtro (0x2e) é o resultado do cálculo
+
# Para fazer o download: <syntaxhighlight lang=bash>
−
# feito pelo filtro tc_index sobre o campo DSCP ... simples, não ?
+
wget http://tele.sj.ifsc.edu.br/~msobral/ubuntu.iso
−
tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 0x2e tcindex classid 2:12 pass_on
+
</syntaxhighlight>
−
</syntaxhighlight>... simples, não ???<br>
+
# Para ver o video: execute '''''vlc''' <nowiki>http://172.18.200.251/~msobral/video.avi</nowiki>''
−
# '''Usando o ''iptables'':''' na tabela ''mangle'' usa-se o alvo DSCP para marcar os datagramas. Para associar um datagrama a uma classe, de acordo com o valor DSCP, deve-se usar o módulo ''dscp'' e os alvos CLASSIFY ou MARK. Ex: <syntaxhighlight lang=bash>
 
−
# Uma qdisc HTB com taxa de 100 kBps e duas classes .. apenas para exemplificar o uso do iptables mais abaixo
 
−
tc qdisc add dev eth0 root handle handle 1:0 htb default 13
 
−
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100kbps ceil 100kbps
 
−
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 80kbps ceil 100kbps
 
−
tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbps ceil 100kbps
 
  
−
# marca os datagramas vindos da rede 172.18.0.0/16 na classe AF41
+
* Qual a taxa de download que foi obtida ?
−
iptables -t mangle -A PREROUTING -s 172.18.0.0/16 -j DSCP --set-dscp-class af41
+
* Como se desempenhou a reprodução do video ?
  
−
# datagramas da classe DSCP AF41 vão para a classe 1:21 do tc
 
−
iptables -t mangle -A FORWARD -m dscp --dscp-class af41 -j CLASSIFY --set-class 1:12
 
−
</syntaxhighlight>
 
  
−
== Policiamento de tráfego ==
+
A reprodução do video poderia ser preservada se a rede priorizasse seu tráfego. Assim, uma forma de priorização será definida no gateway do laboratório. Após essa modificação, repitam os downloads do arquivo e reprodução do video.
  
−
O [http://lartc.org/howto/lartc.adv-filter.policing.html policiamento de tráfego] ocorre na recepção de pacotes por um roteador. Essa função é responsável por assegurar que os pacotes estejam dentro de limites definidos para sua classe. Caso um pacote não satisfaça a condição de policiamento, pode ser descartado ou reclassificado como melhor esforço. Assim, evita-se que fluxos com taxas maiores que a contratada entrem no roteador. Porém isso funciona plenamente somente com a qdisc [http://lartc.org/howto/lartc.qdisc.classful.html#AEN939 CBQ], que por ser muito complexa não foi estudada aqui. De qualquer forma, filtros com policiamento podem ser usados para limitar tráfego de entrada usando a qdisc especial ''ingress''. Essa qdisc não possui parâmetros, pois seu propósito é somente conter filtros para fins de policiamento. Seu funcionamento é limitado, pois provê apenas duas possibilidades: aceitar ou descartar pacotes.
+
* Qual a nova taxa de download obtida ?
 +
* Como se desempenhou a reprodução do video desta vez ?
  
−
'''''Exemplo:'''''
+
== Uma outra experiência ==
−
<syntaxhighlight lang=bash>
 
−
# Cria a qdisc ingress
 
−
tc qdisc add dev eth0 ingress
 
  
−
# Limita o tráfego de entrada vindo de 172.18.0.0/16 a 100kbps, descartando o que exceder esse limite.
+
Desta vez, todos irão usar softphones (ou telefones IP) para escutar uma mensagem gravada em um servidor fora da rede, ao mesmo tempo em que se descarrega um arquivo via HTTP:
−
tc filter add dev eth0 parent ffff: protocol ip u32 match ip src 172.18.0.0/16 police rate 100kbps buffer 10k drop flowid :1
+
# Execute o Jitsi ou use um telefone IP, registrando-o em 192.168.2.1 com o ramal 2000+número_do_seu_computador (com senha=ramal).
 +
# Faça este download:<syntaxhighlight lang=bash>
 +
wget http://172.18.200.251/~msobral/rmu.bin
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
# Execute o wireshark, e deixe-o capturando datagramas UDP na interface eth0.
 +
# Chame o ramal 6666, e escute a mensagem gravada.
 +
# Ao final da chamada, veja a qualidade da stream RTP no wireshark, acessando o menu ''Telephony->RTP->Show All Streams''.
  
−
== Atividade ==
+
Novamente, as chamadas poderiam ser preservadas se a rede priorizasse seu tráfego. Para isso, foi reativada a priorização de datagramas UDP no gateway do laboratório. Após essa modificação, repitam os downloads do arquivo e realização das chamadas.
  
−
Um pequeno provedor possui uma rede como mostrado abaixo. Essa rede é usada para interligar seus clientes, no caso as empresas Ajax e Tabajara.
+
* Qual a nova taxa de download obtida ?
 +
* Que qualidade se obteve para as streams RTP desta vez ?
  
 +
= 29/11: Provendo QoS: conceitos básicos =
  
−
[[imagem:Diffserv-rede1.png]]
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-03.pdf Transparências]
 +
* [http://www.scribd.com/doc/57127868/Cisco-QoS-Concept-and-Design Cisco QoS Concept and Design]
 +
* [http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_2_1_s_v_1_4/qos/configuration/guide/n1000v_qos_queuing.html Estudo de caso: WFQ em roteador Cisco]
 +
* [http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcconman.html#wp4941 Cisco Congestion Management Overview (descreve implementação do WFQ e outros mecanismos)]
  
−
{{collapse top|Configuração para o Netkit}}
+
Como PROVER qualidade de serviço em uma rede ?
−
<syntaxhighlight lang=text>
+
* Como classificar os pacotes, para que sejam tratados de acordo com os requisitos de QoS especificados ?
−
B1[type]=gateway
+
* Como garantir banda para um determinada classe de tráfego ?
−
B2[type]=gateway
+
* Como limitar o uso de banda ?
−
N1[type]=gateway
+
* Como limitar o atraso fim-a-fim de pacotes ?
−
Ajax1[type]=generic
+
* Como limitar a variação de atraso (''jitter'') de pacotes ?
−
Ajax2[type]=generic
+
 
−
Tabajara1[type]=generic
+
Assume-se que a rede considerada seja formada por uma malha de roteadores. Cada interface de um roteador possui uma fila de saída, onde ficam os pacotes à espera de serem transmitidos, como mostrado na figura a seguir. Essas filas possuem tamanho limitado, sendo implementadas por ''buffers'' de memória. Para prover QoS, uma primeira necessidade é controlar '''quando saem pacotes''' por uma interface (para limitar banda), e '''a ordem em que pacotes saem''' (para priorizar pacotes, garantir banda e limitar atrasos). Isso significa atuar principalmente sobre as filas de saída das interfaces de rede.
−
Tabajara2[type]=generic
+
 
 +
[[imagem:Filas-roteador.png]]
  
−
# Preservando o script que cria as regras de QoS nos roteadores.
 
−
# OBS: não esqueça de exportar o projeto do Netkit após terminar a execução da rede ! Ver menu File->Export ...
 
−
B1[preserve]=/root/firewall.sh
 
−
B2[preserve]=/root/firewall.sh
 
−
N1[preserve]=/root/firewall.sh
 
  
−
# Links ...
+
Algumas técnicas conhecidas podem ser usadas para atender os requisitos acima:
−
B1[eth0]=link1:ip=192.168.0.254/24
+
* '''Classificador:''' classifica os pacotes em classes de serviço, de acordo com contratos de tráfego predefinidos. Atua na entrada de pacotes no roteador.
−
B1[eth1]=link2:ip=192.168.10.254/24
+
* '''Disciplinas de filas:''' trata de definir a ordem de saída de pacotes. Com isso se consegue implementar garantia de banda mínima, priorização de tráfego, redução de atraso fim-a-fim e variação de atraso.
−
B1[eth2]=link3:ip=10.0.0.1/28
+
* '''Balde furado (''leaky bucket'')''': trata de definir quando pacotes podem sair. Com isso se pode fazer limitação de banda. Esta é uma técnica fundamental para fazer condicionamento de tráfego (''traffic shaping'');.
  
−
N1[eth0]=link3:ip=10.0.0.2/28
 
−
N1[eth1]=link4:ip=10.0.0.18/28
 
  
−
B2[eth0]=link5:ip=192.168.1.254/24
+
A combinação dessas técnicas possibilita atender os requisitos de QoS especificados para diferentes tipos de tráfego. Elas são amplamente usadas em arquiteturas para QoS na Internet, tais como [[RMU-2012-2#06.2F12:_IntServ:_Servi.C3.A7os_Integrados_na_Internet|Intserv]] e [[RMU-2012-2#06.2F12:_DiffServ:_Servi.C3.A7os_Diferenciados_na_Internet|Diffserv]].
−
B2[eth1]=link6:ip=192.168.11.254/24
 
−
B2[eth2]=link4:ip=10.0.0.17/28
 
  
−
Ajax1[eth0]=link1:ip=192.168.0.1/24
+
== Exercícios ==
−
Ajax2[eth0]=link5:ip=192.168.1.1/24
 
  
−
Tabajara1[eth0]=link2:ip=192.168.10.1/24
+
Resolver os exercícios propostos no final das [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-03.pdf transparências].
−
Tabajara2[eth0]=link6:ip=192.168.11.1/24
 
  
−
# Rotas ...
+
= 04/12: Avaliação 1 =
−
Ajax1[default_gateway]=192.168.0.254
 
−
Ajax2[default_gateway]=192.168.1.254
 
−
Tabajara1[default_gateway]=192.168.10.254
 
−
Tabajara2[default_gateway]=192.168.11.254
 
−
B1[default_gateway]=10.0.0.2
 
−
B2[default_gateway]=10.0.0.18
 
−
N1[route]=192.168.0.0/24:gateway=10.0.0.1
 
−
N1[route]=192.168.10.0/24:gateway=10.0.0.1
 
−
N1[route]=192.168.1.0/24:gateway=10.0.0.17
 
−
N1[route]=192.168.11.0/24:gateway=10.0.0.17
 
−
</syntaxhighlight>
 
−
{{collapse bottom}}
 
  
−
Para implantar a estrutura DiffServ, deve-se começar com o seguinte:
+
A avaliação 1 cobrirá os assuntos estudados até dia 20/11.
  
−
'''i)''' Os roteadores de borda (B1 e B2) devem ser capazes de marcar, policiar e condicionar os datagramas dos clientes. A marcação deve ser feita de acordo com as classes de serviço escolhidas em cada caso.
+
Os exercícios do capítulo 7 do livro ''"Redes de Computadores e a Internet, 5a edição"'', do Kurose, devem ser resolvidos:
 +
# ''Exercicios de fixação:'' 1, 2, 4, 5, 6, 7, 9, 10, 11, 12
 +
# ''Problemas:'' 1, 3, 4, 5, 7, 8, 9, 10, 12, 13, 14, 16, 17, 18, 19
  
−
'''ii)''' O roteador de núcleo (N1) deve ter um PHB capaz de atender tanto classes do tipo ''Encaminhamento Assegurado'' (AF) quanto ''Encaminhamento Acelerado'' (EF). A diferenciação nesse roteador deve ser feita de acordo com a marcação contida nos datagramas - e que foi realizada nos roteadores de borda.
+
É possível que haja questões na avaliação sobre o uso do Asterisk, envolvendo definição de canais SIP e plano de discagem.
  
−
''OBS:'' os links dentro da rede do provedor estão superdimensionados, portanto não apresentam gargalos.
+
Vejam as provas feitas em semestres anteriores:
−
<br>''OBS 2:'' para medir os atrasos de transmissão pode-se usar [http://tele.sj.ifsc.edu.br/~msobral/rmu/delays.py este programa]. Ele fornece uma estimativa dos atrasos médios, máximo, mínimo e jitter.
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/prova2-2011-2.pdf 2011-2]
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/prova2-rec-2011-2.pdf 2011-2 (recuperação)]
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/prova2-2012-1.pdf 2012-1 (recuperação)]
  
−
Tendo a estrutura inicial preparada, resolva os seguintes problemas:
+
= 06/12: Simulação com Opnet =
  
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-04.pdf Roteiro da aula]
  
−
'''1)''' O cliente Ajax contratou um link de 1 Mbps, e Tabajara contratou um link de 2 Mbps. Em ambos os casos, os links são simétricos. Implemente uma estrutura DiffServ nesse provedor, assumindo que ambos clientes usem classes do tipo ''Encaminhamento Assegurado'' (AF).
+
Hoje serão feitos experimentos com o simulador de redes [http://www.opnet.com Opnet]. Esses experimentos mostrarão os descartes de pacotes, além de atrasos de entrega e variação de atraso, para diferentes disciplinas de enfileiramento nos roteadores.
  
−
'''2)''' O cliente Ajax precisa usar parte da capacidade contratada para transmitir streams de audio (voz). Assumindo que as streams estarão codificadas com codec [http://www.speex.org/comparison/ Speex] em modo WB (Wide Band), e que pode haver até 5 streams simultâneas, use a sua estrutura DiffServ para atender essa necessidade.
 
  
−
'''3)''' O cliente Tabajara precisa transmitir streams de audio e videoconferência. Assumindo que possam haver até 4 streams de audio simultâneas, codificadas com Speex em modo NB (Narrow Band), e a stream de video use 256 kbps, use a estrutura DiffServ para atender essa demanda.
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/opnet.tgz Instalador do Opnet (basta descompactar em /home/aluno)]
  
−
= 13/12: DiffServ em roteador Linux (continuação) =
 
  
−
== TAREFA: Leitura da semana ==
+
Obs: deve-se usar o Crossover para rodar o simulador no Ubuntu 10.04. Para facilitar iniciar o simulador, salve o  script abaixo na sua área de trabalho. Use-o para excutar o simulador.
  
−
Leiam até a seção 3.2 (inclusive) deste texto sobre MPLS e Diffserv e preparem-se para apresentá-lo na pŕoxima aula (4a feira - 09/05):
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/opnet Script para executar o simulador]
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/MPLS%20DiffServ-aware%20Traffic%20Engineering.pdf MPLS DiffServ-aware Traffic Engineering]
 
  
−
= 18/12: Revisão =
 
  
−
...
+
[[imagem:Rmu-opnet.png|600px]]
  
−
= 20/12: 1a Avaliação =
 
  
−
== Avaliações de semestres anteriores ==
+
Os modelos de simulação criados ficam localizados em:
  
−
Estas foram as avaliações feitas pelo Emerson no ano passado. A avaliação de 2012-1 será parecida com elas:
+
.cxoffice/Unsupported/drive_c/windows/temp/op_models
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/prova1-2011-1.pdf 2011-1]
 
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/prova1-2011-2.pdf 2011-2]
 
  
−
= 05/02: Revisão da avaliação / Protocolos de Tempo-Real =
+
Assim, pode-se fazer um backup dos modelos caso necessário.
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-22.pdf Transparências]
+
== TAREFA: leitura de um texto ==
  
 +
Leiam este texto sobre um problema relacionado aos atrasos de transmissão percebidos na Internet:
  
−
* '''RTP (''Real Time Protocol''):''' Protocolo de transporte para conteúdo de tempo-real
+
* [http://cacm.acm.org/magazines/2012/2/145415-bufferbloat-whats-wrong-with-the-internet/fulltext Bufferbloat: What is wrong with the Internet ?]
−
** Identificação do tipo do conteúdo que está sendo carregado (codec)
 
−
** Numeração de sequência
 
−
** Marcação de tempo (timestamp) para possibilitar sincronização com a fonte e cálculo de variação de atraso
 
−
** Monitoramento da entrega (recepção da stream)
 
−
** Não provê garantias de QoS !
 
−
* '''RTCP (''Real Time Control Protocol''):''' Protocolo auxiliar ao RTP, para fornecer um feedback dos clientes quanto a streaming.
 
−
** Retorno sobre o desempenho da aplicação e da rede
 
−
** Informações para sincronização de fluxos de video e áudio
 
  
 +
Na aula de 3a feira (11/12) sortearei um aluno para explicar o conteúdo desse artigo.
  
−
[[imagem:Rtp-header.png]]
+
<!--
−
<br>''Cabeçalho RTP''
+
# Obtenha o [http://172.18.200.251/~msobral/itguru.exe instalador do simulador].
 +
# Instale-o em seu computador com o comando '''''wine''' itguru.exe''.
 +
-->
 +
<!-- == TAREFA: leitura da semana ... ==
  
−
== Atividade ==
+
Leiam este textos e preparem-se para apresentá-los em 11/12:
 +
*[http://www.informit.com/articles/article.aspx?p=352991&seqNum=8 WRED]
 +
*[http://searchnetworking.techtarget.com/tip/LAN-QoS-Access-switches-get-intelligent-for-high-stakes-applications LAN QoS] -->
  
−
Essa atividade busca ilustrar os fluxos RTP com um exemplo:
+
= 11/12: QoS em um roteador Linux =
−
# Acesse o servidor de streaming de video RTSP usando o aplicativo ''vlc'': <syntaxhighlight lang=bash>
 
−
vlc rtsp://172.18.200.252/rmu.sdp
 
−
</syntaxhighlight>
 
−
# Execute o wireshark e ative a captura de datagramas UDP.
 
−
# Observe os pacotes RTP capturados pelo Wireshark. Selecione alguns deles e investigue as informações contidas em seu cabeçalho. Procure identificar o codec usado e as marcações de tempo. Compare as marcações de tempo do RTP com os instantes de recepção desses pacotes.
 
  
−
= 07/02: Protocolos de Tempo-Real =
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-13.pdf Transparências]
 +
* [http://opalsoft.net/qos/DS.htm Um bom tutorial sobre disciplinas de filas no Linux]
 +
* [http://lartc.org/howto/ Linux Advanced Routing and Traffic Control Howto:] quase tudo sobre disciplinas de filas (e mais outras coisas).
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-22.pdf Transparências]
+
== Disciplinas de filas (''qdisc'') ==
  
 +
Disciplinas de filas são mecanismos para condicionar a saída de pacotes por uma interface de rede. Com elas se podem priorizar pacotes e limitar taxas de bits de fluxos de saída.
  
−
* '''RTP (''Real Time Protocol''):''' Protocolo de transporte para conteúdo de tempo-real
+
[[imagem:Rmu-Qdisc-overview.png|800px]]
−
** Identificação do tipo do conteúdo que está sendo carregado (codec)
+
<br>''Visão geral do enfileiramento de pacotes em uma interface de saída''
−
** Numeração de sequência
 
−
** Marcação de tempo (timestamp) para possibilitar sincronização com a fonte e cálculo de variação de atraso
 
−
** Monitoramento da entrega (recepção da stream)
 
−
** Não provê garantias de QoS !
 
−
* '''RTCP (''Real Time Control Protocol''):''' Protocolo auxiliar ao RTP, para fornecer um feedback dos clientes quanto a streaming.
 
−
** Retorno sobre o desempenho da aplicação e da rede
 
−
** Informações para sincronização de fluxos de video e áudio
 
  
−
{| border="0" cellpadding="2"
+
As filas contidas nas ''qdisc'' podem ser tratadas de diferentes formas. Isso vai determinar a ordem e o ritmo com que os pacotes são desenfileirados para serem transmitidos. Alguns exemplos de ''qdisc'' implementadas no Linux:
−
|-
+
* '''FIFO:''' pacotes saem por ordem de chegada.
−
|[[imagem:Rtp1.png|200px]]<br>''Localização do RTP na camada de transporte'' ||[[imagem:Rtp-header.png]]<br>    ''Cabeçalho RTP''
+
* '''PRIO:''' pacotes saem de acordo com prioridades.
−
|}
+
* '''SFQ (Stochastic Fair Queueing):''' pacotes saem de forma que os fluxos a que pertencem recebam aproximadamente a mesma taxa de bits.
 +
* '''TBF (Token Bucket Filter):''' pacotes saem limitados a uma certa taxa de bits.
 +
* ... e outras (ver [http://opalsoft.net/qos/DS.htm Differentiated Service on Linux HOWTO] e [http://lartc.org/howto/ Linux Advanced Routing and Traffic Control Howto])
  
 +
Os diagramas abaixo ilustram algumas dessas ''qdisc'':
  
−
* [http://en.wikipedia.org/wiki/RTP_audio_video_profile Tabela de tipos de payload RTP]
+
[[imagem:Rmu-Prio-qdisc.gif|600px]]
 +
<br>''Uma disciplina de filas baseada em prioridades. Fonte: [http://opalsoft.net/qos/DS.htm Differentiated Service on Linux HOWTO]''
  
−
== Atividade ==
 
  
−
Essa atividade busca ilustrar os fluxos RTP com um exemplo:
+
[[imagem:Rmu-Tbf-qdisc.gif|400px]]
−
# Acesse o servidor de streaming de video RTSP usando o aplicativo ''vlc'': <syntaxhighlight lang=bash>
+
<br>''A qdisc TBF (combinada com PRIO), usada para limitar a taxa de saída. Fonte: [http://opalsoft.net/qos/DS.htm Differentiated Service on Linux HOWTO]''
−
vlc rtsp://172.18.200.252/rmu.sdp
 
−
</syntaxhighlight>
 
−
# Execute o wireshark e ative a captura de datagramas UDP.
 
−
# Observe os pacotes RTP capturados pelo Wireshark. Selecione alguns deles e investigue as informações contidas em seu cabeçalho. Procure identificar o codec usado e as marcações de tempo. Compare as marcações de tempo do RTP com os instantes de recepção desses pacotes.
 
−
# Estime o jitter durante a recepção de ao menos 15 segundos de video.
 
  
−
= 14/02: SIP =
 
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-22.pdf Transparências]
+
[[imagem:Rmu-Dsmark.gif|400px]]
 +
<br>''A qdisc DSMARK, usada em uma estrutura Diffserv com Linux. Fonte: [http://opalsoft.net/qos/DS.htm Differentiated Service on Linux HOWTO]''
  
−
== Atividade 1: Ligação SIP ponto a ponto==
+
== Atividade ==
  
−
# Capturar pacotes com wireshark e analisar mensagens SIP (menu Telephony -> Voip Calls -> Graph)
+
Os exercícios sobre disciplinas de filas serão realizados em um cenário em que dois tipos de fluxo são estabelecidos entre duas redes, que estão interligadas por um link ponto-a-ponto. Esse link tem capacidade limitada a 512 kbps. Os fluxos são representados por:
−
# Ouvir a conversa capturada (é necessário usar o CODEC G711)
+
* Uma transferência de um arquivo com HTTP
 +
* Uma chamada VoIP com SIP e RTP
  
 +
[[imagem:Rede-qos-rtp.png]]
  
−
'''Questões:'''
 
−
# Qual o CODEC selecionado por cada parte?
 
−
# Qual a lista de CODECS?
 
−
# Existem mensagens RTCP? Qual a porta?
 
−
# Existe algum registro SIP?
 
−
# Existe a entidade SIP proxy nesse cenário?
 
−
# Existe a entidade RTP proxy nesse cenário?
 
  
 +
A rede a ser usada deve ser criada no [[Netkit]], a partir da configuração abaixo:
  
−
== Atividade  2: Ligações SIP tendo um PABX Asterisk ==
 
−
# Necessário instalar Asterisk na VM do professor e criar contas SIP para cada aluno
 
−
# Capturar pacotes com wireshark e analisar
 
  
−
'''Questões:'''
+
{{collapse top|Arquivo de configuração do Netkit (copie-o para dentro de Lab.conf)}}
−
# Por que a 1a. tentativa de REGISTER tem como resposta "não autorizado"?
+
<syntaxhighlight lang=text>
−
# Existe a entidade SIP proxy nesse cenário?
+
# Global attributes: these values are obtained automatically from menu General->Preferences
−
# Existe a entidade RTP proxy nesse cenário?
+
global[mem]=32
−
#* O fluxo RTP é intermediado?
+
global[compact]=False
−
# Nesse cenário haveria algum problema se uma das partes estiver através de um NAT?
+
global[vm]=0
 +
global[clean]=False
 +
# 32 MB por VM
 +
# Não remove o diretório de trabalho ao final da execução
  
−
= 19/02: NÃO HAVERÁ AULA DEVIDO AO FORUM MUNDIAL =
+
server1[type]=generic
 +
server2[type]=generic
 +
pc[type]=generic
 +
r1[type]=gateway
 +
r2[type]=gateway
  
−
[http://www.aptor.com.br/fmept/login/ Forum Mundial de Educação Profissional no IFSC]
+
# Rede 1: servidores + roteador r1
 +
server1[eth0]=rede1:ip=192.168.1.1/24
 +
server2[eth0]=rede1:ip=192.168.1.2/24
 +
r1[eth0]=rede1:ip=192.168.1.254/24
  
−
= 21/02: NÃO HAVERÁ AULA DEVIDO AO FORUM MUNDIAL =
+
# Rede 2: pc + roteador r2
 +
r2[eth0]=rede2:ip=192.168.2.254/24
 +
pc[eth0]=rede2:ip=192.168.2.1/24
  
−
[http://www.aptor.com.br/fmept/login/ Forum Mundial de Educação Profissional no IFSC]
+
# Link PPP entre Rede 1 e Rede 2 (512 kbps)
 +
r1[eth1]=link:ip=10.0.0.1/30
 +
r2[eth1]=link:ip=10.0.0.2/30
  
−
= 26/02: VoIP e Asterisk =
+
# Roteadores default dos servidores e pc
 +
server1[default_gateway]=192.168.1.254
 +
server2[default_gateway]=192.168.1.254
 +
pc[default_gateway]=192.168.2.254
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-25.pdf Transparências]
+
# Rotas estáticas nos roteadores
−
* [http://www.asterisk.org Site oficial do Asterisk]
+
r1[route]=192.168.2.0/24:gateway=10.0.0.2
−
* [http://www.asteriskguru.com/ Asterisk Guru]
+
r2[route]=192.168.1.0/24:gateway=10.0.0.1
−
* [http://www.voip-info.org/wiki Dicas sobre Asterisk]
 
−
* Livro [http://www.voffice.com.br/index.php/pt/noticiasgrupovoffice/voffice-treinamento/96-voffice-lanca-quinta-geracao-do-guia-de-configuracao-para-o-asterisk- ''Asterisk: Guia de Configuração - 5a geração''], de Flávio Gonçalves.
 
  
 +
# Ativando o servidor HTTP em server1
 +
server1[services]=apache2
 +
</syntaxhighlight>
 +
{{collapse bottom}}
  
−
'''Asterisk:''' uma solução completa de PABX baseado em software, permitindo ligar o mundo IP ao mundo da rede pública de telefonia comutada.
+
=== Roteiro ===
  
−
'''Características Básicas:''' faz tudo que um PABX pequeno e simples faz e pouco mais
+
1) As chamadas VoIP serão simuladas usando uma ferramenta de teste chamada '''siprtp''', que faz parte do projeto [http://www.pjsip.org/ PJSIP]. Seu uso deve ser da seguinte forma:
−
*ˆ Transferência, música de espera, siga-me, etc.
+
* Em ''server2'' executa-se o ''siprtp'' em modo servidor: <syntaxhighlight lang=bash>
−
* Conferência, correio de voz, URA, fila de chamadas, monitoramento de chamadas, integração com o Jabber (Google talk)
+
siprtp --ip-addr=192.168.1.2
 +
</syntaxhighlight>
 +
* Em um dos roteadores deve-se executar o ''wireshark'' (ver menu ''Wireshark''), escolhendo-se a interface ''eth0''.
 +
* Em ''pc'' executa-se o ''siprtp'' em modo cliente, de forma a efetuar uma chamada para ''server2'': <syntaxhighlight lang=bash>
 +
siprtp --ip-addr=192.168.2.1 sip:0@192.168.1.2
 +
</syntaxhighlight>
 +
* Em ''pc'' pode-se monitorar o andamento da chamada teclando-se ''l''. Um sumário como mostrado abaixo deve ser apresentado: <syntaxhighlight lang=text>
 +
>>> l
 +
List all calls:
 +
Call #0: CONFIRMED [duration: 00:00:01.643]
 +
  To: sip:0@127.0.1.1;tag=PKcMBzp6yhIZQG-du1TsYkW1MPmX6L5V
 +
  Signaling quality: got 1st response in 0 ms, connected after: 0 ms
 +
  Stream #0: audio PCMU@8000Hz, 20ms/frame, 8.00KB/s (9.06KB/s +IP hdr)
 +
              RX stat last update: never
 +
                total 77 packets 12.03KB received (14.07KB +IP hdr)
 +
                pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
 +
                      (msec)    min    avg    max    last
 +
                loss period:  0.000  0.000  0.000  0.000
 +
                jitter    :  0.000  0.000  0.000  0.000
 +
              TX stat last update: never
 +
                total 77 packets 12.03KB sent (14.07KB +IP hdr)
 +
                pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
 +
                      (msec)    min    avg    max    last
 +
                loss period:  0.000  0.000  0.000  0.000
 +
                jitter    :  0.000  0.000  0.000  0.000
 +
            RTT delay      :  0.000  0.000  0.000  0.000
 +
</syntaxhighlight>
 +
* A cada vez que se teclar ''l'', um novo sumário pode ser visualizado.
 +
* Quando se quiser encerrar a chamada, deve-se teclar ''h'', e em seguida fornecer o número da chamada (''0'' - zero).
 +
* Após o término da chamada, recarregar os pacotes no ''wireshark'' (tecle no ícone para forçar a atualização). Em seguida selecione ''Telephony->VoIP Calls'' e visualize a chamada realizada. Experimente também selecionar ''Telephony->RTP->Show All streams'' e analisar a stream RTP da chamada. Observe particularmente os valores para ''delta'' e ''jitter''.
  
−
'''Características Avançadas:''' o que seria interessante para grandes empresas
+
2) O experimento da realização da chamada VoIP deve ser repetido, porém realizando-se também uma transferência de arquivo com HTTP entre ''server1'' e ''pc'':
−
* Uso de banco de dados (MySQL), integração com o LDAP, DUNDi, DNS SRV, geração de bilhetagem
+
* Crie um arquivo de 16 MB em ''server1'': <syntaxhighlight lang=bash>
 +
dd if=/dev/urandom of=/var/www/teste.img bs=4096 count=4096
 +
</syntaxhighlight>
 +
* Inicie seu download em ''pc'': <syntaxhighlight lang=bash>
 +
wget http://192.168.1.1/teste.img > log 2>&1 &
 +
</syntaxhighlight>
 +
* Repita os passos do ítem 1, prestando especial atenção aos valores de ''jitter'' e perda de pacotes mostrados no sumário de chamada do ''siprtp''. Compare aos valores obtidos quando foi realizada somente a chamada VoIP.
  
 +
3) Chamadas VoIP são consideradas prioritárias em comparação a transferências de arquivos (e fluxos de dados em geral), pois possuem restrições de atrasos e ''jitter''. Assim, devem ser definidas ''qdisc'' nos roteadores para priorizar pacotes RTP. Isso pode ser feito assim:
 +
* Em ''r1'' e ''r2'' cria-se uma qdisc do tipo ''prio'' na interface ''ppp0''. Os fluxos UDP com port 4000 (stream RTP criada pelo siprtp) devem ser colocados na fila de maior prioridade. Copie os comandos abaixo para dentro do arquivo ''lab/shared/qdisc.sh'':<syntaxhighlight lang=bash>
 +
#!/bin/bash
  
−
[[imagem:Asterisk-ex1.png|400px]]
+
# Limpa as qdisc que porventura existam
−
<br>''Exemplo de cenário de uso do Asterisk''
+
tc qdisc del dev eth1 root
 +
 +
# Cria uma qdisc HTB (Hierarchical Token Bucket) para limitar a saída a uma taxa comparável
 +
# a do link ponto-a-ponto
 +
tc qdisc add dev eth1 root handle 1: htb default 1
 +
tc class add dev eth1  parent 1: classid 1:1 htb rate 256kbit ceil 256kbit
 +
 +
# Cria uma qdisc PRIO, porém subordinada a qdisc TBF
 +
tc qdisc add dev eth1 parent 1:1 handle 10:0 prio
 +
 +
# Datagramas UDP vão pra fila mais prioritária.
 +
tc filter add dev eth1 parent 10: prio 1 protocol ip u32 match ip protocol 17 0xff flowid 10:1
  
 +
# Segmentos TCP vão pra fila menos prioritária.
 +
tc filter add dev eth1 parent 10: prio 1 protocol ip u32 match ip protocol 6 0xff flowid 10:2
  
−
<!-- [[imagem:Asterisk-arch.png|500px]]
+
</syntaxhighlight>
−
<br>''Arquitetura modular do Asterisk'' --->
+
* Repita o ítem 2, e observe as perdas de pacotes e ''jitter'' da chamada VoIP. Houve melhora ?
  
−
== Plano de discagem ==
+
4) Pela capacidade do link é possível haver mais de uma chamada VoIP. Sendo assim:
 +
* Calcule quantas chamadas podem ser atendidas através desse link.
 +
* Teste se de fato essa quantidade de chamadas pode ser atendida, respeitando-se seus requisitos de QoS. Para iniciar mais de uma chamada simultânea execute o ''siprtp'' da seguinte forma: <syntaxhighlight lang=bash>
 +
# inicia duas chamadas
 +
siprtp --ip-addr=192.168.2.1 --count=2
 +
</syntaxhighlight>
  
−
O plano de discagem define como cada chamada deve ser processada. As instruções de processamento residem no arquivo de configuração extensions.conf. O fluxo de processamento de chamadas pode ser visto resumidamente abaixo:
+
<!--1) Em uma rede deseja-se que os fluxos de entrada (que vem de fora da rede) sejam balanceados. Isso significa que nenhum dos fluxos deve poder monopolizar o link de saída dessa rede. Usando o utilitário '''tc''' implemente esse condicionamento de tráfego no seu roteador Linux. <syntaxhighlight lang=bash>
−
 
+
# Cria uma qdisc SFQ, que balanceia os fluxos estatisticamente
−
[[imagem:Asterisk-fluxo.png|400px]]
+
# OBS: assume-se que a interface de saída seja eth0
 +
tc qdisc add dev eth0 root handle 1:0 sfq
 +
</syntaxhighlight>
  
 +
2) Nessa mesma rede, deseja-se modificar o condicionamento de tráfego para que fluxos vindos da rede 172.18.0.0/16 sejam priorizados. Implemente essa modificação no seu roteador. <syntaxhighlight lang=bash>
 +
# Cria uma qdisc PRIO, que usa três filas (bandas) para priorizar fluxos.
 +
# -- a fila mais prioritária tem handle 1:1
 +
# -- a próxima fila tem handle 1:2
 +
# -- a fila menos prioritária tem handle 1:3
 +
# OBS: assume-se que a interface de saída seja eth0
 +
tc qdisc add dev eth0 root handle 1:0 prio
  
−
Um exemplo de plano de discagem simples pode ser visto abaixo:
+
# Datagramas vindos da rede 172.18.0.0/16 vão pra fila mais prioritária.
 +
tc filter add dev eth0 parent 1: prio 1 protocol ip u32 match ip src 172.18.0.0/16 flowid 1:1
  
−
<syntaxhighlight lang=text>
+
# Demais datagramas vão para a fila intermediária.
−
# Chamadas para o número 101 são feitas via SIP para o canal "maria"
+
tc filter add dev eth0 parent 1: prio 2 protocol ip u32 match ip src 0.0.0.0/0 flowid 1:2
−
exten=>101,1,Dial(SIP/maria)
 
−
same=>n,Hangup()
 
−
 
 
−
# Chamadas para "teste" serão atendidas com um som de beep, seguido
 
−
# da reprodução do arquivo de som "hello-world", em seguida outro beep e
 
−
# enfim se encerra a chamada.
 
−
exten=>teste,1,Playback(beep)
 
−
same=>n,Wait(1)
 
−
same=>n,Playback(hello-world)
 
−
same=>n,Wait(1)
 
−
same=>n,Playback(beep)
 
−
same=>n,Hangup
 
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
== Atividade ==
+
3) Configure seu roteador de forma a combinar a priorização de fluxos e o balanceamento entre eles.<syntaxhighlight lang=bash>
−
 
+
# Cria uma qdisc PRIO, que usa três filas (bandas) para priorizar fluxos.
−
Para realizar esses exercícios você deve primeiro instalar o Asterisk na máquina virtual ''rmu-server''. Para testar as chamadas, use o softphone jitsy na máquina real.
+
# -- a fila mais prioritária tem handle 1:1
 +
# -- a próxima fila tem handle 1:2
 +
# -- a fila menos prioritária tem handle 1:3
 +
# OBS: assume-se que a interface de saída seja eth0
 +
tc qdisc add dev eth0 root handle 1:0 prio
 +
 
 +
# Balanceia os fluxos nas duas filas da qdisc PRIO que serão usadas
 +
tc qdisc add dev eth0 parent 1:1 handle 2:0 sfq
 +
tc qdisc add dev eth0 parent 1:2 handle 3:0 sfq
 +
 
 +
# Datagramas vindos da rede 172.18.0.0/16 vão pra fila mais prioritária.
 +
tc filter add dev eth0 parent 1: prio 1 protocol ip u32 match ip src 172.18.0.0/16 flowid 1:1
  
 +
# Demais datagramas vão para a fila intermediária.
 +
tc filter add dev eth0 parent 1: prio 2 protocol ip u32 match ip src 0.0.0.0/0 flowid 1:2
 +
</syntaxhighlight>
  
−
# Criar as seguintes contas SIP e contextos:
+
4) Nessa rede, decidiu-se que fluxos vindos da rede 172.18.0.0/16 devem ter garantidos para si 70 % da capacidade do link, sendo o restante usado para os demais fluxos. Além disso, os fluxos devem estar balanceados. Implemente esse condicionamento de tráfego no seu roteador.
−
#*'''alunos''': Contas 100 e 101
 
−
#*'''professores''': Contas 200 e 201
 
−
#*'''coordenacao:''' Contas 300 e 301
 
−
# Criar um plano de discagem de forma que as contas SIP do contexto alunos só possam atingir outras contas SIP deste contexto. Faça o mesmo para o contexto professores.ˆ Contas SIP do contexto coordenação poderão atingir, além das contas SIP desse contexto, as contas dos contextos ''alunos'' e ''professores''.
 
−
# Implementar caixa de correio de voz para cada extensão e criar uma extensão em cada contexto para permitir a consulta ao correio de voz.
 
  
−
== TAREFA: Leitura da Semana ==
+
5) O utilitário [http://lartc.org/wondershaper/ wondershaper] se propõe a facilitar a limitação das taxas de download e upload. Experimente utilizá-lo, e confira como ele usa ''qdisc'' para fazer isso.
 +
-->
  
−
O texto desta semana diz respeito a SIP Trunking. Leiam até a seção 4 [http://tele.sj.ifsc.edu.br/~msobral/rmu/sip-trunking.pdf deste artigo], e preparem-se para discuti-lo (e apresentá-lo) nesta 5a feira, 14/06.
+
<!-- == TAREFA: leitura da semana ==
  
−
= 28/02: Introdução ao Asterisk (continuação) =
+
O texto a seguir continua a leitura desta semana, tratando da implantação de uma estrutura Diffserv na borda da rede.
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/docs/diffserv-network-edge-2.pdf "Deploying Diffserv at the Network Edge for Tight SLAs, part 2" (''Implantando Diffserv na borda da rede para SLAs apertados)'']
 +
-->
  
−
== Atividade 1: estabelecendo chamadas ==
+
= 13/12: QoS em roteador Linux =
  
−
Nesta aula vamos efetuar chamadas entre softphones, e rastrear as trocas de mensagens realizadas durante uma chamada. Serão usadas as contas criadas na aula anterior.
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-13.pdf Transparências]
−
# Execute duas instâncias do Jitsy, sendo que uma delas deve ser configurada para usar a porta 5060, e a outra deve usar a porta 5061. Essas portas servirão para efetuar trocas de mensagens SIP.
+
* [http://opalsoft.net/qos/DS.htm Um bom tutorial sobre disciplinas de filas no Linux]
−
# Adicione uma conta a cada softphone. Use contas diferentes dentre aquelas criadas na aula anterior.
+
* [http://lartc.org/howto/ Linux Advanced Routing and Traffic Control Howto:] quase tudo sobre disciplinas de filas (e mais outras coisas).
−
# A partir de um softphone faça uma chamada para a conta do outro softphone. Verifique se o softphone destino acusou o recebimento de chamada. Caso isso não tenha ocorrido, verifique seu plano de discagem.
+
* [http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm HTB (Hierarchical Token Bucket) queuing discipline ]
−
# Execute o wireshark, e ponha-o em modo de captura em todas as interfaces (pseudo-interface ''any'').
+
 
−
# Repita a chamada de um softphone a outro. No softphone destino atenda a chamada, e alguns segundos depois encerre-a.
+
== ''qdisc'' com estado (''stateful'') ==
−
# No wireshark interrompa a captura, e em seguida acesse o menu ''Telephony->VoIP Calls''. Selecione uma chamada, e visualize o diagrama de mensagens SIP. Siga cada mensagem SIP (clique no diagrama), e observe a mensagem selecionada no painel de captura do wireshark.
+
 
−
#* Observe o tipo de mensagem (o comando SIP)
+
Com exceção da qdisc PRIO, até o momento foram vistas somente qdisc capazes de conter uma única classe. Regras de priorização e condicionamento de tráfego mais elaboradas precisam, no entanto, combinar ''qdisc'' hierarquicamente. Isso pode ser percebido com um primeiro exemplo.
−
#* Analise os cabeçalhos SIP
 
−
#* Quando disponível, analise a descrição de midia contida nessas mensagens (isso é, veja as mensagens SDP encapsuladas).
 
−
#* Identifique as características da stream de audio, e os correspondentes cabeçalhos RTP.
 
  
−
<!-- == Atividade 2: estabelecendo chamadas entre diferentes PBX Asterisk ==
+
Em um enlace, deseja-se limitar em 100 kbps o tráfego de um conjunto de aplicações. No entanto, cada aplicação também deve ter um limite de uso do enlace, de acordo com o descrito a seguir:
 +
* '''WWW (http e https):''' 40 kbps
 +
* '''SSH:''' 40 kbps
 +
* '''Demais aplicações:''' 20 kbps
  
−
Nesta atividade, vamos realizar chamadas entre softphones registrados em diferentes PBX Asterisk. Para isso, precisaremos estruturar o laboratório da seguinte forma:
 
−
-->
 
  
−
= 05/03: Introdução ao Asterisk (continuação) =
+
O diagrama abaixo mostra como poderia ser modelada a limitação de banda para essas aplicações:
  
−
== Entroncamento entre dois PBXs Asterisk ==
 
  
−
Em um entroncamento SIP (''SIP trunking''), um PBX pode encaminhar chamadas através de um tronco SIP. Essas chamadas podem ser originadas de diferentes formas, tais como telefones IP ou convencionais. Entre os PBX do entroncamento, as chamadas são sinalizadas com SIP e transmitidas com RTP e algum codec.
+
[[imagem:Qdisc-ex1.png]]
  
−
[[imagem:Sip-trunk.png]]
 
  
−
A ativação de um entroncamento SIP entre dois PBX Asterisk pode ser feita seguindo o exemplo abaixo:
+
Como isso poderia ser feito usando o ''tc'' ? Usando apenas as ''qdisc'' que já vimos não parece possível implementar essa regras (na dúvida, você pode tentar). Mas se for usada uma ''qdisc'' capaz de conter várias classes, isso poderia ser realizado. Essa ''qdisc'' limitaria o uso de banda a 100 kbps, e dentro dela existiriam três classes (uma para cada tipo de aplicação). Cada classe, por sua vez, conteria uma ''qdisc'' que poderia impor sua limitação de banda específica. E é exatamente isso que a ''qdisc'' [http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm HTB (Hierarchical Token Bucket)] é capaz de fazer, criando uma hierarquia de classes e ''qdisc'' como mostrado na figura abaixo:
  
−
===PBX Norte===
 
−
* Arquivo <tt>sip.conf</tt>:<syntaxhighlight lang=text>
 
−
# Definição do UAC Sul
 
  
−
[Sul]
+
[[imagem:Qdisc-ex1-diagram.png]]
−
type=user
+
 
−
secret=supersercreta
 
−
host=IP_PBX_Norte
 
−
disallow=all
 
−
allow=ulaw
 
−
;canreinvite=no
 
−
directmedia=no
 
−
context=troncoSIP
 
  
−
[ParaSul]
+
<syntaxhighlight lang=bash>
−
type=peer
+
# adiciona a qdisc raiz na interface eth0
−
fromuser=Norte
+
tc qdisc add dev eth0 root handle 1:0 htb default 23
−
username=Norte
 
−
secret=supersecreta
 
−
host=IP_PBX_Sul
 
−
disallow=all
 
−
allow=ulaw
 
−
;canreinvite=no
 
−
directmedia=no</syntaxhighlight>
 
−
* Arquivo <tt>extensions.conf</tt>:<syntaxhighlight lang=text>
 
−
...
 
−
[troncoSIP]
 
−
# Ligando para a outra central e, na sequência, o "ramal" de destino
 
−
exten => _0.,1,Dial(SIP/ParaSul/${EXTEN:1})
 
−
</syntaxhighlight>
 
  
−
===PBX Sul===
+
# cria a classe filha, que impõe o limite de banda global desta HTB
−
* Arquivo <tt>sip.conf</tt>:<syntaxhighlight lang=text>
+
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100kbps ceil 100kbps
−
# Definição do UAC Norte
+
 
−
[Norte]
+
# cria as classes das aplicações
−
type=user
+
tc class add dev eth0 parent 1:1 classid 1:21 htb rate 40kbps ceil 100kbps
−
secret=supersercreta
+
tc class add dev eth0 parent 1:1 classid 1:22 htb rate 40kbps ceil 100kbps
−
host=IP_PBX_Sul
+
tc class add dev eth0 parent 1:1 classid 1:23 htb rate 20kbps ceil 100kbps
−
disallow=all
 
−
allow=ulaw
 
−
;canreinvite=no
 
−
directmedia=no
 
−
context=troncoSIP
 
  
−
[ParaNorte]
+
# cria os filtros para classificar os datagramas
−
type=peer
+
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 80 0xffff flowid 1:21
−
fromuser=Sul
+
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 443 0xffff flowid 1:21
−
username=Sul
+
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 22 0xffff flowid 1:22
−
secret=supersecreta
 
−
host=IP_PBX_Norte
 
−
disallow=all
 
−
allow=ulaw
 
−
;canreinvite=no
 
−
directmedia=yes
 
−
</syntaxhighlight>
 
−
* Arquivo <tt>extensions.conf</tt>: <syntaxhighlight lang=text>
 
−
[troncoSIP]
 
−
#
 
−
# Ligando para a outra central e, na sequência, o "ramal" de destino
 
−
exten => _0.,1,Dial(SIP/ParaNorte/${EXTEN:1})
 
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
== Atividade: estabelecendo chamadas entre diferentes PBX Asterisk ==
+
A ''qdisc'' HTB funciona da seguinte forma:
 +
* Cada classe possui uma taxa garantida e uma taxa máxima.
 +
* A banda garantida não utilizada por uma classe reverte para para sua classe mãe (um nível acima na hierarquia). Essa sobra pode assim ser aproveitada pelas outras classes filhas.
 +
* Cada classe pode emprestar banda adicional de sua classe mãe até o limite especificado por sua taxa máxima.
 +
* Se houver mais de uma classe filha requisitando banda adicional, a classe mãe divide essa banda proporcionalmente à taxa garantida de cada filha.
 +
* Classes podem ter prioridades, de forma que classes mais prioritárias se apropriam primeiro da banda de sobra (mas a taxa garantida é preservada).
  
−
Nesta atividade, vamos realizar chamadas entre softphones registrados em diferentes PBX Asterisk. Para isso, precisaremos estruturar o laboratório de forma que cada PBX Asterisk possua um tronco SIP com cada um de seus vizinhos. Os usuários SIP serão identificados por 4MM, sendo ''MM'' o número do computador de cada aluno (ex: micro 1 tem usuário 401). Assim, é possível fazer um plano de discagem para encaminhar corretamente as chamadas.
 
  
−
= 07/03: Prática com Asterisk: aplicações e funções típicas de PBX  =
+
Os parâmetros da qdisc HTB estão sumarizados abaixo:
  
−
Algumas funções típicas de PBX são:
+
{| border="1" cellpadding="2"
−
* Transferência de chamadas
+
!Parâmetro
−
* Captura de chamadas
+
!Descrição
−
* Estacionamento de chamadas
+
!Exemplo
−
* Gravação de chamadas
+
|-
−
* Música em espera
+
| rate || taxa garantida || rate 100kbit
−
* Sala de conferência
+
|-
−
* Correio de voz
+
|ceil || taxa máxima || ceil 200 kbit
−
* Siga-me (se ocupado, imediato ou se não atender)
+
|-
−
* Lista negra
+
|prio || prioridade da classe (menores valores = maiores prioridades) || prio 1
−
* Não perturbe
+
|-
−
* Rediscagem
+
|burst || quantidade máxima de bytes de uma classe, dentro da taxa garantida,<br>que podem ser enviados antes de servir outra classe || burst 20 kb
 +
|-
 +
|cburst || quantidade máxima de bytes de uma classe, acima da taxa garabntida,<br>que podem ser enviados antes de servir outra classe || cburst 20 k
 +
|}
 +
 
 +
=== Atividade ===
  
−
Essas funcionalidades podem ser implementadas no próprio PBX ou no telefone. No caso do Asterisk, elas podem ser disponibilizadas diretamente pelo próprio Asterisk, ou ser implementadas no plano de discagem. A figura abaixo ilustra essas possibilidades:
+
A rede abaixo será usada para os experimentos com ''disciplinas de enfileiramento'':
  
−
[[imagem:Recursos-pbx.png]]
 
−
<br>''Funções disponíveis em um PBX Asterisk - figura obtida de: Flávio Gonçalves. Guia de Configuração para Asterisk PBX, 5a edição.''
 
  
−
Para criar essas funções em um PBX Asterisk, é necessário conhecer os recursos que ele oferece. Dentre esses recursos, há aplicações, variáveis, e características (''features''). Hoje serão vistos alguns deses recursos, que usaremos para implantar algumas das funções enumeradas acima.
+
[[imagem:Rede-qos-rtp2.png|680px]]
  
−
== Extensões especiais ==
 
  
−
Além das extensões criadas pelo usuário, o Asterisk apresenta algumas extensões especiais, tais como:
+
{{collapse top | Configuração para o Netkit (salvar em Lab.conf)}}
−
* '''s ''(start)'':''' tem por objetivo tratar qualquer chamada que entre em um contexto e que não tenha um destino específico.
+
<syntaxhighlight lang=text>
−
* '''i ''(invalid)'':''' tem por objetivo tratar entradas inv ́lidas em um menu interativo
+
# Global attributes: these values are obtained automatically from menu General->Preferences
−
* '''t ''(timeout)'':''' Em um menu interativo intercepta a chamada caso o usuário não forneça uma entrada dentro de um período de tempo estipulado.
+
# 32 MB por VM
 +
global[mem]=32
 +
# Não remove o diretório de trabalho ao final da execução
 +
global[clean]=False
 +
 +
server1[type]=generic
 +
server2[type]=generic
 +
pc1[type]=generic
 +
pc2[type]=generic
 +
pc3[type]=generic
 +
r1[type]=gateway
 +
r2[type]=gateway
 +
 +
# Rede 1: servidores + roteador r1
 +
server1[eth0]=rede1:ip=192.168.1.1/24
 +
server2[eth0]=rede1:ip=192.168.1.2/24
 +
r1[eth0]=rede1:ip=192.168.1.254/24
 +
 +
# Rede 2: pc + roteador r2
 +
r2[eth0]=rede2:ip=192.168.2.254/24
 +
pc1[eth0]=rede2:ip=192.168.2.1/24
 +
pc2[eth0]=rede2:ip=192.168.2.2/24
 +
pc3[eth0]=rede2:ip=192.168.2.3/24
 +
 +
# Link PPP entre Rede 1 e Rede 2 (512 kbps)
 +
r1[eth1]=link:ip=10.0.0.1/30
 +
r2[eth1]=link:ip=10.0.0.2/30
 +
 +
# Roteadores default dos servidores e pc
 +
server1[default_gateway]=192.168.1.254
 +
server2[default_gateway]=192.168.1.254
 +
pc1[default_gateway]=192.168.2.254
 +
pc2[default_gateway]=192.168.2.254
 +
pc3[default_gateway]=192.168.2.254
 +
 +
# Rotas estáticas nos roteadores
 +
r1[route]=192.168.2.0/24:gateway=10.0.0.2
 +
r2[route]=192.168.1.0/24:gateway=10.0.0.1
 +
 +
# Ativando o servidor HTTP em server1
 +
server1[services]=apache2:netserver
  
−
== Aplicações ==
+
</syntaxhighlight>
  
−
As aplicações são usadas no plano de discagem. Assim, o processamento de uma chamada se faz pela execução sucessiva de aplicações, de forma a se obter o efeito desejado.
+
{{collapse bottom}}
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+NoOp NoOp] ===
+
1) Na rede usada nos exercícios da semana passada, procuravam-se priorizar as chamadas VoIP usando uma qdisc PRIO. Modifique a disciplina de enfileiramento nos roteadores para que até 2 chamadas possam ser realizadas simultaneamente (com seus requisitos de QoS atendidos). Use a qdisc HTB.
 +
* Qual a banda disponível para as transferências de dados no melhor e no pior caso ? Descubra isso por meio de um experimento na rede simulada (você pode usar o ''netperf'').
  
−
Não faz nada, sendo útil para depurar o plano de discagem. Exemplo:
+
{{collapse top|Regras para criar as disciplinas de filas}}
−
<syntaxhighlight lang=text>
+
<syntaxhighlight lang=bash>
−
exten=>100,1,NoOp(${CONTEXT})
+
#!/bin/bash
−
</syntaxhighlight>
+
 
 +
IFACE=eth1
 +
 
 +
tc qdisc del dev $IFACE root
 +
 
 +
# adiciona a qdisc raiz na interface eth0
 +
tc qdisc add dev $IFACE root handle 1:0 htb default 22
 +
 
 +
# cria a classe filha, que impõe o limite de banda global desta HTB
 +
tc class add dev $IFACE parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+GoTo GoTo] ===
+
# cria as classes das aplicações
 +
tc class add dev $IFACE parent 1:1 classid 1:21 htb rate 180kbit ceil 512kbit
 +
tc class add dev $IFACE parent 1:1 classid 1:22 htb rate 1bps ceil 512kbit
  
−
Pula para um contexto (opcional), extensão, prioridade específica. Exemplo:
+
# cria os filtros para classificar os datagramas
−
<syntaxhighlight lang=text>
+
tc filter add dev $IFACE protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff flowid 1:21
−
exten=>100,1,GoTo(vendas,s,1)
 
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
{{collapse bottom}}
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+GoToIf GoToIf] ===
+
2) Modifique as regras de QoS do exercicio 1 de forma que:
 +
* pc1 tenha garantidos 256 kbps, com garantia de QoS para uma chamada VoIP.
 +
* pc2 tenha garantidos 256 kbps, com garantia de QoS para duas chamadas VoIP.
 +
* pc3 não tenha banda garantida, mas possa usar a banda ociosa.
  
−
Trata-se do comando GoTo condicional. Sua sintaxe é:
+
3) Incremente as regras de QoS do exercício 2 para que tráfego SSH tenha prioridade em relação aos demais tipos de tráfego de dados.
  
−
'''GoToIf'''''(condição?[rótulo se verdade]:[rótulo se falso])''
+
4) Em relação ao exercício 3, ao invés de priorizar SSH modifique as regras para que se garanta ao menos 64 kbps para esse tipo de tráfego.
  
−
Os rótulos podem assumir a forma:
+
5) A disciplina de filas WFQ, existente em roteadores Cisco e usada para garantir banda para classes de serviço, não está implementada no controle de tráfego do Linux. Com as disciplinas existentes no Linux seria possível emular a WFQ ? Caso sim, como isso poderia ser feito ?
 +
* Por exemplo, como emular WFQ de forma que chamadas VoIP tenham peso 5, tráfego SSH tenha peso 2, e demais tipos de tráfego tenha peso 3 ?
 +
* Como se poderia resolver o exercício 2 caso se usasse WFQ ?
  
−
  ''[[contexto],extensão,]prioridade''
+
<!-- == Classificação com iptables ==
  
−
Exemplo:
+
Além de filtros criados com o utilitário ''tc'', a classificação de pacotes pode ser feita também com o auxílio do ''iptables''. Isso possibilita que se usem os seletores do filtro IP, os quais oferecem muitas possibilidades de classificação.
−
<syntaxhighlight lang=text>
 
−
[alunos]
 
  
−
exten=>6111,1,GoToIf($["${CALLERID(num)}" != "6112"]?2:4)
+
Para fins de classificação, deve-se usar a tabela ''mangle''. Além disso, o uso do ''iptables'' pode ser feito de duas formas:
−
same=> n,Dial(SIP/6111,30)
+
# '''Selecionando diretamente a classe de tráfego:''' usando-se o alvo CLASSIFY pode-se definir a classe onde deve ser colocado o pacote: <syntaxhighlight lang=bash>
−
same=> n,Hangup
+
# coloca pacotes do SSH na classe 1:21
−
same=> n,Answer
+
iptables -t mangle -A POSTROUTING -p tcp --dport 22 -j CLASSIFY --set-class 1:21
−
same=> n,Playback(hello-world)
+
</syntaxhighlight>
−
same=> n,Hangup
+
# '''Marcando os pacotes:''' pode-se marcar os pacotes com o ''iptables'', de forma que a marcação seja usada por um filtro do ''tc'' para concluir a classificação: <syntaxhighlight lang=bash>
 +
# filtro do tc que classifica de acordo com a marcação: pacotes com marca "2" são colocados na classe 1:21
 +
tc filter add dev eth0 parent 1:0 protocol ip handle 2 fw flowid 1:21
 +
 
 +
# iptables marca o pacote
 +
iptables -t mangle -A FORWARD -i eth0 -p tcp --dport 22 -j MARK --set-mark 2
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+BackGround Background] ===
+
=== Atividade ===
 +
 
 +
Modifique as regras criadas nos [[RMU-2012-1#Atividade_8|exercícios anteriores]] para que usem:
 +
# iptables para classificação direta (alvo CLASSIFY)
 +
# iptables para marcar pacotes (alvo MARK)
 +
-->
  
−
Toca um arquivo de som como música de fundo. Esse arquivo deve estar em ''/usr/share/asterisk/sounds'', e ser codificado com codec PCM ou WAV.
+
= 18/12: Exercícios =
  
−
Exemplo:
+
Sobre disciplinas de filas e QoS.
  
−
<syntaxhighlight lang=text>
+
'''OBS:''' lista para a avaliação 2: exercícios 20 a 28 do cap. 7 do livro ''Redes de Computadores e a Internet, 5a edição'', de James Kurose.
−
exten=>666,1,Answer
 
−
same=>n,Background(hello-world)
 
−
same=>n,Hangup
 
−
</syntaxhighlight>
 
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Playback Playback] ===
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/prova-filas-demo.pdf Questões de avaliações anteriores]
  
−
Toca um arquivo de som. A diferença em relação a Background é que Playback devolve o controle ao Asterisk (i.e. ao plano de discagem) somente após tocar todo o arquivo. Esse arquivo deve estar em ''/usr/share/asterisk/sounds'', e ser codificado com codec PCM ou WAV.
+
= 20/12: Avaliação 2 =
  
−
Exemplo:
+
= 05/02: Diffserv em roteador Linux =
  
−
<syntaxhighlight lang=text>
+
* [http://datatracker.ietf.org/wg/diffserv/charter/ Página do Grupo de Trabalho DiffServ no IETF]
−
exten=>666,1,Answer
+
* [http://datatracker.ietf.org/doc/rfc2475/ RFC 2475: Definição da Arquitetura DiffServ]
−
same=>n,Playback(hello-world)
+
* [http://datatracker.ietf.org/doc/rfc3246/?include_text=1 RFC 3246: Comportamento de um PHB Expedited Forwarding (EF)]
−
same=>n,Hangup
+
* [http://datatracker.ietf.org/doc/rfc3248/ RFC 3248: Uma Revisão Alternativa com Atraso Limitado para PHB EF]
−
</syntaxhighlight>
+
* [http://datatracker.ietf.org/doc/rfc2597/ RFC 2597: Comportamento de um PHB Assured Forwarding (AF)]
 +
 
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-06.pdf Transparências]
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Wait Wait] ===
+
Diffserv é um modelo para provimento de QoS para Internet, em que fluxos são ''classificados'' e então tratados de forma ''diferenciada'' dentro da rede. A proposta, contida na [http://www.ietf.org/rfc/rfc2475.txt RFC 2475], visa definir um modelo flexível e escalável para atendimento de requisitos de QoS.
 +
* '''Flexibilidade:''' o tratamento de cada classe de tráfego é uma decisão da gerência da rede, e assim não é especificada na proposta.
 +
* '''Escalabilidade:''' a priorização e condicionamento de tráfego a serem feitos nos roteadores se basearão nas classes de tráfego, e não nos fluxos individuais que passam pela rede (compare com [[RMU-2012-1#21.2F03:_IntServ:_Servi.C3.A7os_Integrados_na_Internet|IntServ]]). Isso proporciona a agregação dos fluxos, que são rotulados com as classes de serviço, facilitando a tarefa dos roteadores no núcleo da rede.
  
−
Força uma espera durante o processamento da chamada.
+
''Obs: as figuras abaixo foram obtidas em um [http://www.cisco.com/en/US/technologies/tk543/tk766/technologies_white_paper09186a00800a3e2f_ps6610_Products_White_Paper.html artigo da Cisco]''
  
−
Exemplo:
 
  
−
<syntaxhighlight lang=text>
+
Uma visão geral da arquitetura DiffServ pode ser vista na figura abaixo:
−
exten=>666,1,Answer
 
−
same=>n,Playback(hello-world)
 
−
same=>n,Wait(1)
 
−
same=>n,Playback(beep)
 
−
same=>n,Hangup
 
−
</syntaxhighlight>
 
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Answer Answer] e [http://www.voip-info.org/wiki/view/Asterisk+cmd+Hangup Hangup] ===
 
  
−
Answer atende uma chamada. Hangup termina uma chamada.
+
[[imagem:Diffserv-arch.png]]
 +
<br>''Arquitetura DiffServ''
  
−
Exemplo:
 
  
−
<syntaxhighlight lang=text>
+
Diversos elementos compõem a arquitetura:
−
exten=>666,1,Answer
+
* '''Domínios DiffServ:''' conjuntos de roteadores onde se aplicam uma determinada classificação e diferenciação de tráfego, definidas pela gerência da rede.
−
same=>n,Playback(hello-world)
+
* '''Roteadores de borda:''' roteadores que classificam fluxos que entram num domínio DiffServ. Essa tarefa de classificação e condicionamento de fluxos de entrada pode ser complexa. Por esses roteadores também passam fluxos que saem do domínio, para serem entregues a sistemas finais.
−
same=>n,Hangup
+
* '''Roteadores de núcleo:''' roteadores internos de um domínio DiffServ, que encaminham fluxos já classificados. Esses roteadores verificam a conformidade desses fluxos às regras definidas pela gerência da rede para as classes de serviço. Assim, pacotes desses fluxos estão sujeitos a priorizações, enfileiramentos, e mesmo descartes, dependendo das restrições de QoS que foram  definidas. Essas regras compõem o que se chama de ''Comportamento por Salto'' (''PHB - Per-Hop Behaviour''), representada no diagrama contido na figura abaixo.
−
</syntaxhighlight>
 
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Set Set] ===
 
  
−
Modifica o valor de uma variável.
+
[[imagem:Diffserv-tcb.png]]
 +
<br>''PHB - Per-Hop Behaviour''
  
−
Exemplo:
 
  
−
<syntaxhighlight lang=text>
+
A classificação feita nos roteadores de borda mapeia características dos fluxos para um número de 6 bits. Assim, podem haver até 64 classes de serviço em um domínio DiffServ. Esse número, chamado de ''DSCP - DiffServ Code Point'', é inscrito no campo ToS dos datagramas IPv4 (ou no campo Traffic Class de datagramas IPv6), como mostrado abaixo:
−
exten=>666,1,Set(Tentativas=1)
 
−
same=>2,Dial(SIP/666,10)
 
−
same=>3,Set(Tentativas=${Tentativas}+1)
 
−
same=>4,GoToIf($[${Tentativas} < 2]?2:5)
 
−
same=>5,Hangup
 
−
</syntaxhighlight>
 
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Log Log] ===
+
{| border="0" cellpadding="2"
 +
|-
 +
|[[imagem:Ip-tos.png|400px]] ||[[imagem:Dscp.png|400px]]
 +
|}
  
−
Grava um texto qualquer no log do Asterisk.
 
  
−
Exemplo:
+
<!-- [[imagem:Ip-headers.png]] -->
  
−
<syntaxhighlight lang=text>
+
Os comportamentos por salto podem ser:
−
exten=>666,1,Log(DEBUG,"Chamada para 666")
+
* '''Default PHB:''' pacotes com DSCP de valor 000000 (zero) são tratados com melhor esforço. Isso também deve ser aplicado para pacotes cujos DSCP tenham valores não reconhecidos pelo roteador. Ver maiores detalhes na [http://www.ietf.org/rfc/rfc2474.txt RFC 2474].
−
same=>n,Dial(SIP/666,10)
+
* '''Class-selector PHB:''' pacotes com DSCP xxx000 são tratados de acordo com uma política tradicional de precedência IP (i.e. classes de tráfego descritas no campo ToS). Também descrito na [http://www.ietf.org/rfc/rfc2474.txt RFC 2474]
−
same=>n,Hangup
+
* '''Expedited Forwarding PHB (EF):''' semelhante ao serviço garantido do IntServ. Desenhado para prover um serviço com baixas taxas de perda, baixa latência e jitter, e uma largura de banda garantida. Deve ser usado somente por aplicações críticas. O valor do DSCP deve ser 10110 (ver [http://www.ietf.org/rfc/rfc2598.txt RFC 2598]
−
</syntaxhighlight>
+
* '''Assured Forwarding PHB (AF):''' semelhante ao serviço de carga controlada do IntServ. Define quatro classes de serviço, sendo que cada uma tem três níveis de precedência de descarte.
  
−
== Variáveis ==
 
  
−
O uso de variáveis no Asterisk possui funcionamento semelhante àquele encontrado nas linguagens de programação, permitindo ao “programador” utilizar variáveis já definidas pelo Asterisk bem como definir suas próprias variáveis. As definições das variáveis devem ser feitas no arquivo ''extensions.conf''.
+
[[imagem:Aff-codepoint-table.png]]
 +
<br>''Classes de serviço e precedências de descarte em AF PHB''
  
−
A sintaxe para trabalhar com variáveis no Asterisk é semelhante a do [http://manpages.ubuntu.com/manpages/hardy/man1/bsd-csh.1.html c-shell], porém as variáveis definidas pelo usuário não são sensíveis a caixa, ou seja, VAR e var referem-se à mesma variável.
+
== Uma interpretação sobre Diffserv ==
−
* Para definir uma variável: ''VAR=valor''
 
−
* Para obter o valor de uma variável: ''${VAR}''
 
  
−
Existem três tipos de variáveis:
+
Um domínio DiffServ é composto por roteadores com comportamentos predefinidos (''PHB - Per Host Behavior''), e que policiam e condicionam fluxos de acordo com as classes de tráfego existentes. Dentre os quatro grupos de classes, vale destacar estes dois:
−
* '''Variáveis globais:''' Variáveis que estarão disponíveis a todos os canais e contextos em um plano de discagem. Essas devem ser declaradas dentro do contexto ''[globals]'' existente no arquivo ''extensions.conf'' ou utilizando a função ''GLOBAL()'' no plano de discagem.
 
−
* '''Variáveis do canal:''' Variáveis que estão associadas especificamente com uma unica ligação. São definidas durante a chamada e só estão disponíveis para os participantes desta chamada. O Asterisk já define algumas variáveis específicas ao canal (Ex: ${CALLERID(num)}).
 
−
* '''Variáveis de ambiente:''' São as variáveis obtidas do sistema operacional. Estas são referenciadas através do comando ENV. Ex: ''${ENV(path)}.''
 
  
−
Abaixo se pode ver um exemplo de plano de discagem que usa variáveis:
+
* '''Encaminhamento Acelerado (Expedited Forwarding - EF):''' proporciona baixo atraso, baixo jitter, baixa perda de pacotes. Uma boa discussão sobre esse PHB pode ser encontrada [http://opalsoft.net/qos/DS-16.htm aqui].
 +
** ''Principal característica:'' definir um limite superior para atraso de encaminhamento em um nodo, assumindo que a fila de saída esteja usualmente vazia ou seja curta.
 +
** ''Finalidade:'' atender fluxos que necessitam de atrasos e jitter estritos.<br>De acordo com a [http://datatracker.ietf.org/doc/rfc3246/?include_text=1 RFC 3246]: <syntaxhighlight lang=text>
 +
Intuitively, the definition of EF is simple: the rate at which EF
 +
traffic is served at a given output interface should be at least the
 +
configured rate R, over a suitably defined interval, independent of
 +
the offered load of non-EF traffic to that interface.
 +
</syntaxhighlight> ... e complementado pela [http://datatracker.ietf.org/doc/rfc3248/?include_text=1 RFC 3248]:<syntaxhighlight lang=text>
 +
For a traffic stream not exceeding a configured rate the goal of the
 +
DB PHB is a strict bound on the delay variation of packets through a
 +
hop.
  
−
<syntaxhighlight lang=text>
+
Traffic MUST be policed and/or shaped at the source edge (for
−
[globals]
+
example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in
−
; definicao de uma variavel global
+
order to get such a bound.  However, specific policing and/or shaping
−
VENDAS=SIP/6112
+
rules are outside the scope of the DB PHB definition.  Such rules
 +
MUST be defined in any per-domain behaviors (PDBs) composed from the
 +
DB PHB.
 +
</syntaxhighlight>
 +
* '''Encaminhamento Assegurado (Assured Forwarding - AF):''' oferece diferentes probabilidades de que pacotes sejam encaminhados.
 +
** ''Principal característica:'' a probabilidade de que pacotes sejam encaminhados depende dos recursos alocados (''buffer'' e largura de banda) para cada classe AF e respectivas precedências de descartes em caso de congestionamento.
 +
** ''Finalidade:'' limitar a vazão de fluxos, respeitando rajadas em certa medida.<br>De acordo com a [http://datatracker.ietf.org/doc/rfc2597/?include_text=1 RFC 2597]:<syntaxhighlight lang=text>
 +
In a DS node, the level of forwarding assurance of an IP packet thus
 +
depends on (1) how much forwarding resources has been allocated to
 +
the AF class that the packet belongs to, (2) what is the current load
 +
of the AF class, and, in case of congestion within the class, (3)
 +
what is the drop precedence of the packet.
 +
</syntaxhighlight>
  
−
[alunos]
+
As outras classes são ''Default PHB'', que corresponde a um serviço melhor esforço, e ''Class Selector PHB'', que se baseia na interpretação convencional do campo ToS do cabeçalho IP.
−
; definicao de uma variavel global atraves do comando Global e aplicacao Set
 
−
exten=> 6666,1,Set(GLOBAL(COMPRAS)=SIP/6113)
 
−
exten=> 6666,2,NoOp(${GLOBAL(COMPRAS)})
 
  
−
; definicao de uma variavel especifica ao canal
+
A implantação de um domínio DiffServ usando roteadores Linux implica usar as regras de controle de tráfego do Linux (via utilitários ''tc'' e ''iptables'') para criar essas classes. Para isso precisamos ter claro o seguinte:
−
exten=> 7777,1,Set(teste=1)
+
* Como policiar tráfego que entra em um domínio DiffServ ?
−
exten=> 7777,n,NoOp(${teste})
+
* Como modificar o campo DSCP de datagramas IP, e como usar o valor desse campo para identificar uma classe de tráfego ?
−
exten=> 7777,n,Set(teste=$[${teste} + 1])
+
* Como limitar atrasos de encaminhamento ?
−
exten=> 7777,n,NoOp(${teste})
+
* Como garantir banda a um fluxo agregado, com certa tolerância a rajadas ?
−
exten=> 7777,n,Hangup
+
* Como fazer descartes com diferentes probabilidades e precedências ?
−
</syntaxhighlight>
 
  
−
== Funções implementadas no próprio Asterisk ==
+
== Marcação DiffServ ==
  
−
=== [http://www.voip-info.org/wiki/view/Music+on+Hold Música de espera] ===
+
No DiffServ, o campo DSCP de datagramas IP é usado para indicar a classe a que pertence cada datagrama. Com base nesse valor, cada roteador pode aplicar seu PHB e assim condicionar o tráfego. Existem duas formas de marcar o campo DSCP e usar esse valor para classificação:
 +
# '''Usando o ''tc'':''' isso pode ser feito diretamente com o ''tc'', por meio de uma qdisc especial chamada [http://lartc.org/howto/lartc.adv-qdisc.dsmark.html DSMARK] combinada a filtros. Essa forma de marcar e classificar datagramas é um pouco mais complexa, como se pode ver por este exemplo: <syntaxhighlight lang=bash>
 +
# Cria a qdisc DSMARK com 64 índices.
 +
tc qdisc add dev eth0 handle 1:0 root dsmark indices 64 set_tc_index
  
−
O Asterisk permite o uso de MP3 como música de espera, porém MP3 são arquivos complicados de se trabalhar pois requerem o uso de aplicações externas para que possam ser reproduzidos, como por exemplo [http://manpages.ubuntu.com/manpages/lucid/man1/mpg123.bin.1.html mpg123]. Seu funcionamento também pode não agradar muito já que em alguns casos a música pode ser reproduzida em alta rotação além de elevar a carga de processamento da máquina no caso de soluções de grande porte.
+
# Cria uma classe DSMARK para definir o valor do DSCP para 0xb8
 +
tc class change dev eth0 classid 1:1 dsmark mask 0x3 value 0xb8
  
−
A partir da versão 1.2 do Asterisk se sugere não mais usar o ''mpg123''. O melhor é converter arquivos MP3 para um formato que o Asterisk trate nativamente, como por exemplo, ''wav'' ou ''pcm'' (μLaw). A ferramenta [http://manpages.ubuntu.com/manpages/karmic/en/man1/ffmpeg.1.html ffmpeg] pode ser usada para converter arquivos MP3 para WAV ou PCM.
+
</syntaxhighlight>... e para escolher uma classe dependendo do valor DSCP:<syntaxhighlight lang=bash>
 +
# Filtro que usa o valor do DSCP para calcular o valor do handle de outro filtro. Quer dizer,  
 +
# este filtro serve apenas para selecionar outro filtro.
 +
tc filter add dev eth0 parent 1:0 protocol ip prio 1 tcindex mask 0xfc  shift 2
  
−
<syntaxhighlight lang=bash>
+
# Uma qdisc HTB com taxa de 100 kBps e duas classes .. apenas para exemplificar o uso do filtro tc_index mais abaixo
−
# convertendo o arquivo musica.mp3 para musica.wav e musica.pcm
+
tc qdisc add dev eth0 parent 1:0 handle 2:0 htb default 13
−
ffmpeg -i musica.mp3 -ar 8000 -ac 1 -ab 64 musica.wav -ar 8000 -ac 1 -ab 64 -f mulaw
+
tc class add dev eth0 parent 2:0 classid 2:1 htb rate 100kbps ceil 100kbps
−
musica.pcm -map 0:0 -map 0:0
+
tc class add dev eth0 parent 2:1 classid 2:12 htb rate 80kbps ceil 100kbps
−
</syntaxhighlight>
+
tc class add dev eth0 parent 2:1 classid 2:13 htb rate 20kbps ceil 100kbps
 +
 
 +
# O filtro ao final selecionado escolhe a classe a receber o pacote. Esse filtro está vinculado a uma qdisc
 +
# com handle 2:0, e se ativado classifica o datagrama na classe 2:12. O handle do filtro (0x2e) é o resultado do cálculo
 +
# feito pelo filtro tc_index sobre o campo DSCP ... simples, não ?
 +
tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 0x2e tcindex classid 2:12 pass_on
 +
</syntaxhighlight>... simples, não ???<br>
 +
# '''Usando o ''iptables'':''' na tabela ''mangle'' usa-se o alvo DSCP para marcar os datagramas. Para associar um datagrama a uma classe, de acordo com o valor DSCP, deve-se usar o módulo ''dscp'' e os alvos CLASSIFY ou MARK. Ex: <syntaxhighlight lang=bash>
 +
# Uma qdisc HTB com taxa de 100 kBps e duas classes .. apenas para exemplificar o uso do iptables mais abaixo
 +
tc qdisc add dev eth0 root handle handle 1:0 htb default 13
 +
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100kbps ceil 100kbps
 +
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 80kbps ceil 100kbps
 +
tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbps ceil 100kbps
  
−
Os arquivos de música devem ficar em um diretório especificado para cada contexto, conforme definido no arquivo [http://www.voip-info.org/wiki/view/Asterisk+config+musiconhold.conf ''musiconhold.conf'']:
+
# marca os datagramas vindos da rede 172.18.0.0/16 na classe AF41
 +
iptables -t mangle -A PREROUTING -s 172.18.0.0/16 -j DSCP --set-dscp-class af41
  
−
<syntaxhighlight lang=text>
+
# datagramas da classe DSCP AF41 vão para a classe 1:21 do tc
−
# configuracao no arquivo musiconhold.conf
+
iptables -t mangle -A FORWARD -m dscp --dscp-class af41 -j CLASSIFY --set-class 1:12
−
[alunos]
 
−
mode=files
 
−
directory=/var/lib/asterisk/moh
 
−
sort=random
 
−
# deve-se colocar os arquivos wav e/ou pcm no diretorio especificado acima
 
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
Para testar a música em espera no plano de discagem, pode-se usar a aplicação [http://www.voip-info.org/wiki/view/Asterisk+cmd+MusicOnHold MusicOnHold]:
+
== Policiamento de tráfego ==
 +
 
 +
O [http://lartc.org/howto/lartc.adv-filter.policing.html policiamento de tráfego] ocorre na recepção de pacotes por um roteador. Essa função é responsável por assegurar que os pacotes estejam dentro de limites definidos para sua classe. Caso um pacote não satisfaça a condição de policiamento, pode ser descartado ou reclassificado como melhor esforço. Assim, evita-se que fluxos com taxas maiores que a contratada entrem no roteador. Porém isso funciona plenamente somente com a qdisc [http://lartc.org/howto/lartc.qdisc.classful.html#AEN939 CBQ], que por ser muito complexa não foi estudada aqui. De qualquer forma, filtros com policiamento podem ser usados para limitar tráfego de entrada usando a qdisc especial ''ingress''. Essa qdisc não possui parâmetros, pois seu propósito é somente conter filtros para fins de policiamento. Seu funcionamento é limitado, pois provê apenas duas possibilidades: aceitar ou descartar pacotes.
  
−
<syntaxhighlight lang=text>
+
'''''Exemplo:'''''
−
exten=>667,1,Set(CHANNEL(musicclass)=alunos)
+
<syntaxhighlight lang=bash>
−
same=>n,Answer
+
# Cria a qdisc ingress
−
same=>n,MusicOnHold()
+
tc qdisc add dev eth0 ingress
−
same=>n,Dial(SIP/667)
+
 
−
same=>n,Hangup
+
# Limita o tráfego de entrada vindo de 172.18.0.0/16 a 100kbps, descartando o que exceder esse limite.
 +
tc filter add dev eth0 parent ffff: protocol ip u32 match ip src 172.18.0.0/16 police rate 100kbps buffer 10k drop flowid :1
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+call+queues Filas de atendimento] ===
+
== TAREFA: Leitura da semana ==
 +
 
 +
Leiam até a seção 3.2 (inclusive) deste texto sobre MPLS e Diffserv e preparem-se para apresentá-lo na aula da 5a feira - 14/02:
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/MPLS%20DiffServ-aware%20Traffic%20Engineering.pdf MPLS DiffServ-aware Traffic Engineering]
  
−
Amplamente utilizadas nos sistemas de 0800. A configuração é feita no arquivo ''queues.conf'':
+
= 07/02: DiffServ em roteador Linux (continuação) =
  
−
<syntaxhighlight lang=text>
+
== Atividade ==
−
[fila-suporte]
 
−
musicclass=default
 
−
strategy=ringall; roundrobin, rrmemory
 
−
timeout=10
 
−
wrapuptime=30
 
−
periodic-announce = em-breve
 
−
periodic-announce-frequency=60
 
−
member=>SIP/6111
 
−
member=>SIP/6112
 
−
</syntaxhighlight>
 
  
−
No plano de discagem a fila de atendimento pode ser usada da seguinte forma:
+
Um pequeno provedor possui uma rede como mostrado abaixo. Essa rede é usada para interligar seus clientes, no caso as empresas Ajax e Tabajara.
  
−
<syntaxhighlight lang=text>
 
−
[suporte]
 
−
exten=> s,1,Set(CHANNEL(musicclass)=suporte)
 
−
exten=> s,2,Playback(bem-vindo)
 
−
exten=> s,3,Queue(fila-suporte)
 
−
</syntaxhighlight>
 
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+callgroups+and+pickupgroups Captura de chamadas] ===
+
[[imagem:Diffserv-rede1.png]]
  
−
A captura possibilita que se puxe uma chamada de um colega no mesmo grupo de
+
{{collapse top|Configuração para o Netkit}}
−
chamadas. Isso evita que se tenha que levantar para atender um telefone do seu vizinho que não para de tocar. A captura pode ser feita discando *8 (isso pode ser alterado no arquivo [http://www.voip-info.org/wiki/view/Asterisk+config+features.conf ''features.conf'']).
+
<syntaxhighlight lang=text>
 +
B1[type]=gateway
 +
B2[type]=gateway
 +
N1[type]=gateway
 +
Ajax1[type]=generic
 +
Ajax2[type]=generic
 +
Tabajara1[type]=generic
 +
Tabajara2[type]=generic
  
 +
# Preservando o script que cria as regras de QoS nos roteadores.
 +
# OBS: não esqueça de exportar o projeto do Netkit após terminar a execução da rede ! Ver menu File->Export ...
 +
B1[preserve]=/root/firewall.sh
 +
B2[preserve]=/root/firewall.sh
 +
N1[preserve]=/root/firewall.sh
  
 +
# Links ...
 +
B1[eth0]=link1:ip=192.168.0.254/24
 +
B1[eth1]=link2:ip=192.168.10.254/24
 +
B1[eth2]=link3:ip=10.0.0.1/28
  
−
[[imagem:Call-capture.png|400px]]
+
N1[eth0]=link3:ip=10.0.0.2/28
−
<br>''Captura de chamadas - figura obtida de: Flávio Gonçalves. Guia de Configuração para Asterisk PBX, 5a edição.''
+
N1[eth1]=link4:ip=10.0.0.18/28
  
−
Para habilitar a captura de chamadas é suficiente definir a que grupo de chamadas cada canal pertence (parâmetro ''callgroup''), e de que grupos se pode capturar chamadas (parâmetro ''pickupgroup''). No caso de canais SIP isso fica em ''sip.conf'':
+
B2[eth0]=link5:ip=192.168.1.254/24
 +
B2[eth1]=link6:ip=192.168.11.254/24
 +
B2[eth2]=link4:ip=10.0.0.17/28
 +
 
 +
Ajax1[eth0]=link1:ip=192.168.0.1/24
 +
Ajax2[eth0]=link5:ip=192.168.1.1/24
 +
 
 +
Tabajara1[eth0]=link2:ip=192.168.10.1/24
 +
Tabajara2[eth0]=link6:ip=192.168.11.1/24
  
−
<syntaxhighlight lang=text>
+
# Rotas ...
−
[joaozinho]
+
Ajax1[default_gateway]=192.168.0.254
−
callgroup=1
+
Ajax2[default_gateway]=192.168.1.254
−
pickupgroup=1,2
+
Tabajara1[default_gateway]=192.168.10.254
−
...
+
Tabajara2[default_gateway]=192.168.11.254
 +
B1[default_gateway]=10.0.0.2
 +
B2[default_gateway]=10.0.0.18
 +
N1[route]=192.168.0.0/24:gateway=10.0.0.1
 +
N1[route]=192.168.10.0/24:gateway=10.0.0.1
 +
N1[route]=192.168.1.0/24:gateway=10.0.0.17
 +
N1[route]=192.168.11.0/24:gateway=10.0.0.17
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
{{collapse bottom}}
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+call+parking Estacionamento de chamadas] ===
+
Para implantar a estrutura DiffServ, deve-se começar com o seguinte:
  
−
O estacionamento de chamadas é feito no arquivo ''features.conf'' fazendo uso dos seguintes parâmetros:
+
'''i)''' Os roteadores de borda (B1 e B2) devem ser capazes de marcar, policiar e condicionar os datagramas dos clientes. A marcação deve ser feita de acordo com as classes de serviço escolhidas em cada caso.
−
* '''parktext''': Extensão utilizada para fazer o estacionamento de chamadas, após invocá-la o sistema irá indicar em qual posição a chamada atual foi estacionada.
 
−
*ˆ '''parkpos''': Define o número de vagas para o estacionamento de chamadas.
 
−
* '''context''': Define o nome do contexto para o estacionamento de chamadas. É necessário incluir este contexto nos demais contextos que poderão usar o estacionamento de chamadas.
 
−
* '''parkingtime''': Se definida, indica o tempo máximo que uma chamada poderá ficar estacionada. Se este tempo estourar o sistema irá fazer uma ligação para o ramal que estacionou a chamada em questão.
 
  
 +
'''ii)''' O roteador de núcleo (N1) deve ter um PHB capaz de atender tanto classes do tipo ''Encaminhamento Assegurado'' (AF) quanto ''Encaminhamento Acelerado'' (EF). A diferenciação nesse roteador deve ser feita de acordo com a marcação contida nos datagramas - e que foi realizada nos roteadores de borda.
  
−
[[imagem:Parking-calls.png]]
+
'''''OBS:''''' os links dentro da rede do provedor estão superdimensionados, portanto não apresentam gargalos.
−
<br>''Estacionamento de chamadas - figura obtida de: Flávio Gonçalves. Guia de Configuração para Asterisk PBX, 5a edição.''  
+
<br>'''''OBS 2:''''' para medir os atrasos de transmissão pode-se usar [http://tele.sj.ifsc.edu.br/~msobral/rmu/delays.py este programa]. Ele fornece uma estimativa dos atrasos médios, máximo, mínimo e jitter. <br>'''''OBS 3:''''' a [[RMU-2012-2#Marca.C3.A7.C3.A3o_DiffServ|marcação dos datagramas IP]] deve ser feita via Netfilter, cujas regras devem ser criadas por meio do utilitário [[RMU-2012-2#Uma_introdu.C3.A7.C3.A3o_ao_iptables|iptables]]. A classificação dos datagramas pode ser feita tanto com [[RMU-2012-2#Uma_introdu.C3.A7.C3.A3o_ao_iptables|iptables]] quanto com ''tc''.
  
−
Abaixo se pode ver um exemplo de plano de discagem que usa estacionamento de chamadas:
+
Tendo a estrutura inicial preparada, resolva os seguintes problemas:
  
−
<syntaxhighlight lang=text>
 
−
[vendas]
 
  
−
include=>parkedcalls
+
'''1)''' O cliente Ajax contratou um link de 1 Mbps, e Tabajara contratou um link de 2 Mbps. Em ambos os casos, os links são simétricos. Implemente uma estrutura DiffServ nesse provedor, assumindo que ambos clientes usem classes do tipo ''Encaminhamento Assegurado'' (AF).
  
−
exten=>6200,1,Dial(SIP/6200,30,tT)
+
'''2)''' O cliente Ajax precisa usar parte da capacidade contratada para transmitir streams de audio (voz). Assumindo que as streams estarão codificadas com codec [http://www.speex.org/comparison/ Speex] em modo WB (Wide Band), e que pode haver até 5 streams simultâneas, use a sua estrutura DiffServ para atender essa necessidade.
−
exten=>6200,n,Hangup
 
−
</syntaxhighlight>
 
  
−
== Atividade ==
+
'''3)''' O cliente Tabajara precisa transmitir streams de audio e videoconferência. Assumindo que possam haver até 4 streams de audio simultâneas, codificadas com Speex em modo NB (Narrow Band), e a stream de video use 256 kbps, use a estrutura DiffServ para atender essa demanda.
  
−
Nesta aula faremos experimentos usando ATA, Telefone IP e softphones junto com o Asterisk. Em seguida, testaremos algumas das funções de PBX apresentadas hoje.
+
= 14/02: DiffServ em roteador Linux (continuação) =
  
−
# Instale um ATA ou telefone IP, fazendo com que se registre via SIP em seu Asterisk. Teste-o realizando chamadas para um softphone, e vice-versa.
+
Para concluir o estudo sobre Diffserv, será feito um projeto com esta outra rede:
−
# Crie uma fila de atendimento com dois membros e música de espera.
 
−
# Crie um serviço de estacionamento de chamadas. Para testá-lo serão necessários ao menos três telefones (os dois que estabelecem originalmente a chamada, e um terceiro para capturar uma chamada estacionada).
 
  
−
= 12/03: Prática com Asterisk (continuação) =
+
[[imagem:Diffserv-rede2.png]]
  
−
== Atividade 1: implantando funções de PBX ==
 
−
 
−
# Faça o estacionamento de chamadas.
 
−
# Implante a captura de chamadas.
 
−
 
−
== Atividade 2: criando uma infraestrutura com múltiplos servidores Asterisk ==
 
−
 
−
Nesta atividade vamos integrar os servidores Asterisk de todos os alunos no laboratório. Usaremos uma estrutura hierárquica como ilustrado abaixo:
 
  
 +
{{collapse top|Configuração para o Netkit}}
 +
<syntaxhighlight lang=text>
 +
B1[type]=gateway
 +
B2[type]=gateway
 +
B3[type]=gateway
 +
B4[type]=gateway
 +
N1[type]=gateway
 +
N2[type]=gateway
 +
N3[type]=gateway
 +
N4[type]=gateway
 +
Ajax1[type]=generic
 +
Ajax2[type]=generic
 +
Tabajara1[type]=generic
 +
Tabajara2[type]=generic
 +
Lexcorp1[type]=generic
 +
Lexcorp2[type]=generic
 +
 +
# Preservando o script que cria as regras de QoS nos roteadores.
 +
# OBS: não esqueça de exportar o projeto do Netkit após terminar a execução da rede ! Ver menu File->Export ...
 +
B1[preserve]=/root/firewall.sh
 +
B2[preserve]=/root/firewall.sh
 +
B3[preserve]=/root/firewall.sh
 +
B4[preserve]=/root/firewall.sh
 +
N1[preserve]=/root/firewall.sh
 +
N2[preserve]=/root/firewall.sh
 +
N3[preserve]=/root/firewall.sh
 +
N4[preserve]=/root/firewall.sh
 +
 +
# Links ...
 +
B1[eth0]=link-ajax1:ip=192.168.1.254/24
 +
B1[eth1]=link-b1-n1:ip=10.0.0.1/30
 +
B2[eth0]=link-tab2:ip=192.168.12.254/24
 +
B2[eth1]=link-lex1:ip=192.168.21.254/24
 +
B2[eth2]=link-b2-n2:ip=10.0.0.5/30
 +
B3[eth0]=link-tab1:ip=192.168.11.254/24
 +
B3[eth1]=link-b3-n3:ip=10.0.0.9/30
 +
B4[eth0]=link-ajax2:ip=192.168.2.254/24
 +
B4[eth1]=link-lex2:ip=192.168.22.254/24
 +
B4[eth2]=link-b4-n4:ip=10.0.0.13/30
 +
 +
N1[eth0]=link-b1-n1:ip=10.0.0.2/30
 +
N1[eth1]=link-n1-n2:ip=10.0.0.17/30
 +
N1[eth2]=link-n1-n3:ip=10.0.0.21/30
 +
 +
N2[eth0]=link-b2-n2:ip=10.0.0.6/30
 +
N2[eth1]=link-n1-n2:ip=10.0.0.18/30
 +
N2[eth2]=link-n2-n4:ip=10.0.0.25/30
 +
 +
N3[eth0]=link-b3-n3:ip=10.0.0.10/30
 +
N3[eth1]=link-n1-n3:ip=10.0.0.22/30
 +
N3[eth2]=link-n3-n4:ip=10.0.0.29/30
 +
 +
N4[eth0]=link-b4-n4:ip=10.0.0.14/30
 +
N4[eth1]=link-n2-n4:ip=10.0.0.26/30
 +
N4[eth2]=link-n3-n4:ip=10.0.0.30/30
 +
 +
Ajax1[eth0]=link-ajax1:ip=192.168.1.1/24
 +
Ajax2[eth0]=link-ajax2:ip=192.168.2.1/24
 +
 +
Tabajara1[eth0]=link-tab1:ip=192.168.11.1/24
 +
Tabajara2[eth0]=link-tab2:ip=192.168.12.1/24
 +
 +
Lexcorp1[eth0]=link-lex1:ip=192.168.21.1/24
 +
Lexcorp2[eth0]=link-lex2:ip=192.168.22.1/24
 +
 +
# Rotas ...
 +
Ajax1[default_gateway]=192.168.1.254
 +
Ajax2[default_gateway]=192.168.2.254
 +
Tabajara1[default_gateway]=192.168.11.254
 +
Tabajara2[default_gateway]=192.168.12.254
 +
Lexcorp1[default_gateway]=192.168.21.254
 +
Lexcorp2[default_gateway]=192.168.22.254
 +
B1[default_gateway]=10.0.0.2
 +
B2[default_gateway]=10.0.0.6
 +
B3[default_gateway]=10.0.0.10
 +
B4[default_gateway]=10.0.0.14
 +
 +
# Ajax1 <-> Ajax2
 +
N1[route]=192.168.1.0/24:gateway=10.0.0.1
 +
N1[route]=192.168.2.0/24:gateway=10.0.0.18
 +
N2[route]=192.168.1.0/24:gateway=10.0.0.17
 +
N2[route]=192.168.2.0/24:gateway=10.0.0.26
 +
N4[route]=192.168.1.0/24:gateway=10.0.0.25
 +
N4[route]=192.168.2.0/24:gateway=10.0.0.13
 +
 +
# tab1 <-> tab2
 +
N3[route]=192.168.11.0/24:gateway=10.0.0.9
 +
N3[route]=192.168.12.0/24:gateway=10.0.0.30
 +
N4[route]=192.168.11.0/24:gateway=10.0.0.29
 +
N4[route]=192.168.12.0/24:gateway=10.0.0.25
 +
N2[route]=192.168.11.0/24:gateway=10.0.0.26
 +
N2[route]=192.168.12.0/24:gateway=10.0.0.5
 +
 +
# Lex1 <-> Lex2
 +
N2[route]=192.168.21.0/24:gateway=10.0.0.5
 +
N2[route]=192.168.22.0/24:gateway=10.0.0.26
 +
N4[route]=192.168.21.0/24:gateway=10.0.0.25
 +
N4[route]=192.168.22.0/24:gateway=10.0.0.13
 +
</syntaxhighlight>
 +
{{collapse bottom}}
  
−
[[imagem:Asterisk-hierarquia-lab.png]]
+
Nessa rede deve-se implantar um serviço do tipo ''Olímpico''. Esse serviço é composto por três classes:
  
 +
*'''Ouro:''' provê links de 2 Mbps com tolerância a rajadas de até 512 kB
 +
*'''Prata:''' provê links de 1 Mbps com tolerância a rajadas de até 256 kB
 +
*'''Bronze:''' provê links que aproveitam a capacidade ociosa da rede, porém limitados a 2 Mbps
  
−
Como se pode ver, o servidor Asterisk do professor terá o papel de encaminhar chamadas entre os servidores dos alunos. Mas para que isso seja viável e escalável, cada aluno deve usar uma numeração de ramais que possa ser univocamente identificada. Assim, cada servidor Asterisk deve numerar seus ramais da seguinte forma:
+
Além disso, clientes podem contratar capacidade da rede para tráfego sensível a atraso (ex: VoIP).
  
−
* ''21XX:'' números do aluno 1
+
# Implante o serviço Olímpico nessa rede. Ajax contratou um link Ouro, Tabajara contratou Prata, e Lexcorp contratou bronze.
−
* ''22XX:'' números do aluno 2
+
# Modifique a rede para que Ajax e Tabajara contratem Ouro, e Lexcorp contrate Bronze
−
* ''23XX:'' números do aluno 3
+
# Modifique a rede para que Tabajara contrate também capacidade adicional para até 4 chamadas VoIP simultâneas (assuma uso de PCM-u).
−
* ''30XX:'' números do aluno 10
+
# '''DESAFIO:''' e se for necessário implementar precedências de descarte para as classes AF ? Por exemplo, dentro da classe AF1 podem existir três precedências de descarte: AF11, AF12 e AF13. A ideia é que, em caso de congestionamento, pacotes marcados com AF13 sejam descartados antes de AF12, e estes sejam descartados antes de AF11. Investigue e demonstre como isso poderia ser feito no Linux (dica: veja a disciplina de filas [http://www.opalsoft.net/qos/DS-27.htm GRED]).
−
* ''34XX:'' números do aluno 14
+
 
 +
= 16/02: IntServ: Serviços Integrados na Internet =
 +
 
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-06.pdf Transparências]
 +
* [http://www.cisco.com/en/US/products/ps6611/products_white_paper09186a00800ade1a.shtml Signaled QoS (Cisco)]
 +
* [http://tools.ietf.org/html/rfc1633 RFC 1633 (Intserv Architecture)]
 +
** [http://tools.ietf.org/html/rfc2210 RFC 2210: The Use of RSVP with IETF Integrated Services]
 +
** [http://tools.ietf.org/html/rfc2211 RFC 2211: Specification of the Controlled-Load Network Element Service]
 +
** [http://tools.ietf.org/html/rfc2212 RFC 2212: Specification of Guaranteed Quality of Service]
 +
* [http://tools.ietf.org/html/rfc2998 RFC 2998: Intserv over Diffserv]
  
−
As funções de PBX imlementadas nas atividades anteriores devem ser preservadas.
+
'''IntServ''': serviços integrados para provimento de QoS fim-a-fim. Nesse modelo, fluxos de pacotes entre um  transmissor e um receptor têm seus requisitos de QoS atendidos pela infraestrutura de rede. Para isso, são efetuadas reservas de recursos (largura de banda, priorização) em todos os roteadores ao longo do caminho entre transmissor e um receptor.
  
  
−
''' Questões para refletir:'''
+
IntServ é introduzido pela [http://tools.ietf.org/html/rfc1633 RFC 1633].
−
# E se o servidor Asterisk do professor estiver '''fora''' da rede do laboratório ? Nesse caso, a comunicação entre ele e os servidores dos alunos deve passar pelo NAT.
 
−
# E se os telefones IP estiverem em redes diferentes, entre as quais se usa NAT ? Por exemplo, se um telefone IP estiver na rede da escola (172.18.0.0/16) e outro estiver no laboratório de Redes 2 (192.168.2.0/24) ? Isso funciona sem problemas, ou deve ser feita alguma coisa em especial ?
 
  
−
= 14/03: Prática com Asterisk: STUN e integração com DNS =
 
  
−
== STUN: Session Traversal Utilities for NAT ==
+
[[imagem:Intserv1.jpeg]]
  
−
* [http://tools.ietf.org/html/rfc5389 RFC 5389]
 
  
 +
Elementos da arquitetura IntServ:
 +
* '''Especificação de fluxo:''' define as características de um fluxo e os recursos que ele precisa da rede:
 +
** '''''TSpec (Traffic Specification)''''': especificação de características de um fluxo (gerada pelo transmissor): ''TokenBucketRate, TokeBucketSize, PeakRate, MinimumPolicedUnit, MaximumPacketSize''
 +
** '''''RSpec (Reservation Specification):''''' especificação de características de uma reserva de recursos (gerada pelo receptor). Contém os mesmos parâmetros que TSpec, além de uma classe de serviço (garantida, carga controlada ou melhor-esforço) e um filtro que descreve o fluxo (endereços IP dos pares, ports TCP ou UDP).
 +
* '''RSVP (Resource Reservation Protocol):''' protocolo de sinalização para negociar reservas de recursos ao longo do caminho a ser usado pelo fluxo.
  
−
'''''Ou: um quebra-galho para resolver os problemas de outro quebra-galho ...'''''
 
  
 +
[[imagem:Intserv-model.jpg]]
  
−
O estabelecimento de uma chamada VoIP implica iniciar e manter duas streams de áudio (uma em cada sentido da comunicação). Cada stream usa o protocolo RTP, cujas PDUs são transportadas dentro de datagramas UDP. Portanto, cada telefone IP precisa alocar um port UDP, por onde serão recebidas as PDUs RTP.
 
  
−
[[imagem:Voip-call.png|600px]]
+
A sinalização RSVP ocorre em duas etapas:
−
<br>''Diagrama que mostra uma chamada VoIP típica intermediada por um PBX. A sinalização se faz através do PBX, mas as streams de áudio RTP são estabelecidas diretamente entre os telefones VoIP.''
+
# O transmissor do fluxo envia mensagens PATH para o receptor. Essas mensagens contém a descrição do fluxo (''TSpec'').
 +
# Se aceitar a especificação de fluxo contida na mensagem PATH, o receptor responde com uma mensagem RESV. Essa mensagem especifica a reserva a ser feita ao longo do caminho entre transmissor e receptor (i.e. contém um ''RSpec'') . Cada roteador ao longo do caminho testa se a reserva pode ser satisfeita, e em caso afirmativo propaga a mensagem RESV ao próximo roteador.
  
 +
'''Obs:''' o pedido de reserva feito pelo transmissor (mensagens PATH) deve ocorrer ''periodicamente''. Caso os roteadores ou o receptor fiquem um certo tempo sem receber uma mensagem PATH, as reservas correspondentes são canceladas.
 +
<br>'''Obs 2:''' fluxos são unidirecionais, portanto as reservas são feitas também de forma unidirecional.
  
−
As informações necessárias para transmitir as PDUs da stream RTP são informadas no momento em que se inicia a chamada. Um dos telefones IP usa o protocolo SIP para solicitar uma chamada com outro telefone (mensagem INVITE). Dentro dessa mensagem INVITE é encapsulada uma mensagem SDP, que contém as informações necessárias para criar uma stream de áudio, tais como codecs aceitos, e endereço IP e port UDP onde o telefone iniciador da chamada espera receber as PDUs RTP. Se o telefone chamado aceitar a chamada, sua resposta SIP terá status ''200 OK'', e encapsulará uma mensagem SDP contendo a identificação dos codecs que aceita utilizar, além de seu endereço IP e port UDP onde espera receber as PDUs RTP. Assim, com base nas informações contidas nas mensagens SDP, os telefones IP podem estabelecer as streams de áudio em ambas direções. A figura abaixo ilustra uma mensagem SDP encapsulada em uma mensagem SIP INVITE.
+
[[imagem:Rsvp-signaling.jpg]]
  
  
−
[[imagem:Sdp.png|800px]]
+
Segundo um [http://www.cisco.com/en/US/technologies/tk543/tk766/technologies_white_paper09186a00800a3e2f_ps6610_Products_White_Paper.html artigo da Cisco], IntServ possui como '''pontos fortes''':
−
<br>''O endereço IP e o port UDP para estabelecer a stream RTP são informados dentro da mensagem SDP, quando o telefone VoIP tenta iniciar uma chamada com SIP (mensagem INVITE). A lista de codecs da mensagem SDP foi omitida por simplicidade.''
+
* Um tipo de serviço garantido que limita o atraso fim-a-fim e proporciona uma largura de banda para o tráfego que se adequade às especificações da reserva de recursos.
 +
* Um tipo de serviço de carga controlada, o qual provê um desempenho superior a melhor esforço, além de um atraso fim-a-fim baixo sob cargas leves ou moderadas na rede.
 +
* Possibilidade de proporcionar a qualidade de serviço pedida para cada fluxo na rede, contanto que tenha sido sinalizado usando RSVP e existam recursos disponíveis.
  
  
−
Mas como essas streams de áudio podem ser estabelecidas se existir um ou mais gateways NAT entre os telefones VoIP ? A mensagem SDP com a descrição dos dados de uma stream é preenchida usando o endereço IP e port UDP do telefone VoIP. No entanto, a existência de um gateway NAT faz com que o endereço IP e port UDP desse telefone VoIP sejam diferentes para quem estiver fora de sua rede. O correto seria ter na mensagem SDP o endereço IP e port UDP que serão usados após passar o NAT - quer dizer, os valores que serão visíveis para o outro telefone VoIP. Para isso foi criado o serviço STUN (''Session Traversal Utilities for NAT''), que possibilita que um telefone VoIP (ou qualquer outro cliente) descubra seu endereço IP e port UDP visíveis para quem estiver do outro lado do gateway NAT. A figura abaixo ilustra como o STUN poderia ser usado para essa finalidade.
+
... mas tem também '''pontos fracos''':
−
 
+
* Cada equipamento ao longo do caminho de um pacote, incluindo os sistemas finais (ex: PCs e servidores), precisam entender e usar RSVP e serem capazes de sinalizar a QoS pedida.
−
[[imagem:STUN.png|600px]]
+
* Reservas de recursos em cada equipamento ao longo do caminho são ''"brandas"'', o que significa que precisam ser renovadas periodicamente. Com isso, há um tráfego de sinalização adicional que contribui para o aumento da carga na rede, o qual aumenta a chance de que a reserva expire se os pacotes de renovação forem perdidos.
−
<br>''Cenário em que se poderia usar STUN''
+
* A manutenção de estados sobre as reservas de recursos em cada roteador, combinada com controle de admissão e uma maior quantidade de memória necessária para suportar um grande número de reservas, aumenta a complexidade de cada nó da rede ao longo do caminho.
−
 
+
* Como informação sobre estados para cada reserva precisa ser mantida em todos os roteadores ao longo do caminho, torna-se um desafio manter centenas de milhares de fluxos que passem pelo núcleo da rede.
−
 
 
−
O STUN foi criado para ser usado imediatamente antes de iniciar uma transmissão UDP. Como mostrado na figura abaixo, um cliente envia a um servidor STUN uma mensagem de pedido de vinculação (''binding request''), que deve usar como port UDP de origem o mesmo port que se pretende usar para a stream de áudio. Esse servidor STUN deve estar fora da rede, de forma que o pedido de vinculação por ele recebido seja modificado pelo NAT. A resposta do servidor STUN (''binding response'') contém o endereço IP e número de port UDP que apareceram no pedido de vinculação. Com isso o cliente consegue descobrir como esses valores deverão aparecer após passarem pelo NAT. Assim, a mensagem SDP pode ser preenchida com os valores apropriados para a stream de áudio.
 
−
 
 
−
 
 
−
[[imagem:Stun-diagram.png|600px]]
 
−
<br>''Exemplo de mensagens trocadas com STUN''
 
  
 +
A seguinte explicação (obtida [http://www.tacs.eu/Analyses/Internet/ip%20qos%20architectures/int-serv_architecture.htm aqui]) aponta outras limitações do Intserv, e comenta sobre sua adoção em redes corporativas e de provedores:
  
−
'''Deve-se notar que o STUN não faz milagre !''' Como apontado no início do texto, STUN é um quebra-galho criado para tentar resolver os problemas de outro quebra-galho (no caso, o NAT). Para que o STUN funcione, o NAT deve permitir que datagramas UDP vindos de outro endereço IP (o telefone VoIP na outra ponta da ligação) acessem o endereço IP e port UDP que foram alocados quando da consulta do cliente para o servidor STUN. Como visto em uma [[RMU-2012-1#11.2F04:_Firewall|aula anterior]], isso só é possível se o NAT for do tipo [http://en.wikipedia.org/wiki/Full_cone_NAT ''full cone''], [http://en.wikipedia.org/wiki/Restricted_cone_NAT ''restricted cone''] ou [http://en.wikipedia.org/wiki/Port_restricted_cone_NAT ''port restricted cone'']. Quer dizer, se o NAT for do tipo [http://en.wikipedia.org/wiki/Symmetric_NAT simétrico], o STUN não funcionará. E muitos NAT em equipamentos proprietários são do tipo simétrico (ao contrário do Linux, que implementa um NAT ''port restricted cone'') ...
 
−
 
−
=== NAT e Asterisk ===
 
−
 
−
O Asterisk pode ajudar a viabilizar a comunicação com telefones VoIP que estão atrás de gateways NAT. Na definição de cada canal SIP devem-se incluir as opções:
 
  
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
−
nat=yes
+
Although IntServ is a straightforward QoS model, end-to-end service guarantees cannot be supported unless all
−
qualify=yes
+
nodes along the route support IntServ. This is obviously so because any best-effort node along any route can
−
directmedia=no
+
treat packets in such a way that the end-to-end service agreements are violated. In the case of end-end
 +
implementation of IntServ QoS model, it is recognized by the industry that the support of per-flow guarantees
 +
in the core of the Internet will pose severe scalability problems. Therefore, scalability is a key
 +
architectural concern for IntServ, since it requires end-to-end signaling and must maintain a per-flow
 +
soft state at every router along the path. Other concerns are, how to authorize and prioritize
 +
reservation requests, and what happens when signaling is not deployed end-to-end. Because of
 +
these issues, it is generally accepted that IntServ is a better candidate for enterprise
 +
networks (i.e., for access networks), where user flows can be managed at the desktop user level,
 +
than for large service provider backbones. A hybrid model (RSVP-DS) that uses RSVP at the edges
 +
and DiffServ in the backbone has been proposed and seems to be winning consensus as a backbone
 +
service architecture concept.
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
[http://www.voip-info.org/wiki/view/Asterisk+sip+nat Aqui] tem uma boa explicação sobre o que fazem essas opções.
+
= 19/02: Serviços Integrados na Internet =
  
−
'''OBS:''' isso só funciona quando o Asterisk está no caminho da stream de áudio. No caso de telefones VoIP que conversam diretamente, só resta STUN ou alguma outra técnica do tipo ...
+
== Atividade ==
  
−
=== Servidores STUN ===
+
* [[RMU-2012-2#06.2F12:_Simula.C3.A7.C3.A3o_com_Opnet|Instalação do Opnet]]
  
−
Existe uma implementação de um [http://www.vovida.org/applications/downloads/stun/ servidor STUN para Linux] (disponível no Ubuntu via apt). Assim, basta instalá-lo em um computador e usá-lo como servidor STUN, contanto que ele esteja ''do outro lado'' do NAT. No entanto, existem inúmeros servidores STUN públicos, conforme mostrado na listagem abaixo:
+
Para visualizar o efeito de usar IntServ, iremos utilizar o simulador Opnet.
−
 
+
# Execute o simulador e abra o modelo ''RSVP''.
−
<syntaxhighlight lang=text>
+
## Leia a descrição do modelo, que explica o que ele pretende mostrar.
−
provserver.televolution.net
+
## No menu ''Scenarios->Switch scenario'' selecione ''configuration''. Em  seguida, execute o modelo.
−
sip1.lakedestiny.cordiaip.com
+
## Selecione o menu ''Results-Compare results'' para visualizar os resultados, observando os atrasos fim-a-fim nos sistemas finais e nos roteadores.
−
stun1.voiceeclipse.net
+
## Veja os atributos relativos ao RSVP nos sistemas finais e nos roteadores. Veja também no perfil da aplicação (abra o pop-up menu de ''Application Definition'' e selecione ''Edit Attributes->Application Definitions->VoIP RSVP used->Description''). Além disso, observe as especificações de fluxos RSVP contidas em ''Qos Attribute Config'': abra o pop-up menu, selecione ''Edit Attributes'' e visualize ''RSVP Flow Specification->row 0''.
−
stun01.sipphone.com
+
# O que acontece se for modificada a especificação de fluxo RSVP ? Experimente aumentar a largura de banda (''TokenBucketRate'') ou tolerância a rajada (''TokenBucketSize''). Isso pode ser feito em ''Qos Attribute Config'': abra o pop-up menu, selecione ''Edit Attributes'' e visualize ''RSVP Flow Specification->row 0''.
−
stun.callwithus.com
+
## Execute o modelo com a nova especificação de fluxo.
−
stun.counterpath.net
+
## Visualize os resultados. O que mudou em relação à primeira execução ?
−
stun.endigovoip.com
+
# Qual o efeito de haver um roteador sem suporte a RSVP no meio do caminho ?
−
stun.ekiga.net (alias for stun01.sipphone.com)
+
## Duplique o cenário, salvando-o com o nome ''RSVP 2''.
−
stun.ideasip.com (no XOR_MAPPED_ADDRESS support)
+
## Adicione um roteador entre ''Router 1'' e ''Router 2''. Conecte-o a esses outros roteadores com links ''PP DS0''.
−
stun.internetcalls.com
+
## Refaça a simulação, e observe os resultados. O que mudou em relação ao atraso fim-a-fim ?
−
stun.ipns.com
+
# Ainda sobre o roteador sem RSVP que foi adicionado, faça a seguinte modificação:
−
stun.noc.ams-ix.net
+
## Conecte o computador ''client_no_RSVP'' ao novo roteador (e desconecte-o de ''Router 1''). Use um link ''PP DS0'.
−
stun.phonepower.com
+
## Execute a simulação.
−
stun.phoneserve.com
+
## Visualize os resultados. O que mudou em relação à simulação anterior (e em relação à primeira simulação) ? Observe especialmente o atraso fim-a-fim.
−
stun.rnktel.com
+
 
−
stun.softjoys.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
+
 
−
stunserver.org see their usage policy
+
[[imagem:Rsvp-model-2.png|600px]]
−
stun.sipgate.net
+
<br>''O modelo RSVP com mais um roteador.''
−
stun.sipgate.net:10000
 
−
stun.voip.aebc.com
 
−
stun.voipbuster.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
 
−
stun.voxalot.com
 
−
stun.voxgratia.org (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
 
−
stun.xten.com
 
−
numb.viagenie.ca (http://numb.viagenie.ca) (XOR_MAPPED_ADDRESS only with rfc3489bis magic number in transaction ID)
 
−
stun.ipshka.com inside UA-IX zone russsian explanation at http://www.ipshka.com/main/help/hlp_stun.php
 
−
</syntaxhighlight>
 
  
−
[http://www.voip-info.org/wiki/view/STUN Maiores detalhes sobre servidores STUN]
+
<!-- === Sobre o bug no Opnet ===
  
−
== Integração com DNS ==
+
Não se pode dizer que seja um ''bug'' no simulador, mas às vezes os resultados da simulação não podem ser visualizados. Quando isso acontece, parece que as estatísticas da simulação não foram coletadas. Mas consegui fazer com que funcionasse (se bem que aninda não entendi ao certo o que causa o problema ... talvez um arquivo de log perdido ?).
  
−
* [http://www.cisco.com/en/US/docs/voice_ip_comm/sip/proxies/2.1/administration/guide/ddns.html Uma boa explicação no site da Cisco]
+
'''Solução:'''
 +
# Remova todo o subdiretório ''.cxoffice'':<syntaxhighlight lang=bash>rm -rf /home/aluno/.cxoffice</syntaxhighlight>
 +
# Reinstale o simulador: <syntaxhighlight lang=bash>cd /home/aluno
 +
wget http://172.18.200.251/~msobral/opnet.tgz
 +
tar xzf opnet.tgz</syntaxhighlight>
 +
-->
  
−
Uma rede representada por um determinado domínio DNS pode ter seu próprio servidor SIP. Seria conveniente que o endereço desse servidor pudesse ser obtido com uma mera consulta DNS. Isso se assemelha ao caso do correio eletrônico, em que o endereço do MTA de um domínio pode ser descoberto consultando-se seu registro MX. De fato, existe uma forma de descobrir o servidor SIP associado a um domínio DNS. Para isso, deve-se explorar o uso de registros DNS do tipo SRV.
+
== TAREFA: Leitura da semana ==
  
−
Um registro SRV, cuja definição se encontra na [http://tools.ietf.org/html/rfc2782 RFC 2782], possibilita descobrir o nome DNS e o port (TCP ou UDP) de um servidor que responde por um determinado serviço. No caso do SIP de um domínio, o registro SRV deve ser especificado da seguinte forma:
+
* Para apresentar nesta 5a feira (21/02)
  
−
_sip._udp SRV 0 5060 nome.do.servidor.sip.
+
Leia [http://www.ciscopress.com/articles/article.asp?p=426640&seqNum=2 este artigo] da Cisco sobre engenharia de tráfego em redes MPLS. Em particular, estude a seção que trata de RSVP-TE, uma versão do protocolo RSVP adaptada para o uso em MPLS.
  
−
... sendo ''0'' a prioridade desse servidor (positivo, e quanto menor, maior a prioridade), 5060 o port onde ele atende requisições, e ''nome.do.servidor.sip'' seu nome DNS.
+
= 21/02: Firewall =
  
−
O próprio serviço STUN pode ser obtido usando registros SRV, mas isso depende do telefone VoIP (ou do PBX, caso ele esteja fazendo papel de participante em uma chamada VoIP). Nesse caso, o registro SRV deve ser definido da seguinte forma:
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-08.pdf Transparências]
 +
* [http://www.sans.org/reading_room/whitepapers/firewalls/ Uma coleção de textos técnicos sobre firewalls e suas aplicações]
  
−
_stun._udp SRV 0 3478 nome.do.servidor.stun.
+
== Uma introdução ao iptables ==
  
−
== Atividade ==
+
O filtro IP do Linux se chama [http://www.netfilter.org/ NetFilter], e suas regras são configuradas por meio do utilitário [https://help.ubuntu.com/community/IptablesHowTo iptables] (ver também seu [http://manpages.ubuntu.com/manpages/natty/man8/iptables.8.html manual]). Com iptables se podem adicionar ou remover regras do Netfilter, além de consultar estatísticas sobre essas regras (ex: contadores dos pacotes e bytes que selecionaram cada regra). As regras são agrupadas em conjuntos denominados ''chains'' ("cadeias"), as quais estão relacionadas com o contexto que cada pacote está sendo analisado. Existem três ''chains'' predefinidas:
 +
* '''INPUT:''' contém as regras a serem aplicadas aos pacotes destinados ao próprio firewall.
 +
* '''OUTPUT:''' contém as regras a serem aplicadas aos pacotes transmitidos pelo próprio firewall.
 +
* '''FORWARD:''' contém as regras a serem aplicadas aos pacotes em trânsito pelo firewall (isto é, pacotes recebidos de uma interface e sendo encaminhados através de outra interface).
 +
Assim, usando-se o iptables podem ser adicionadas regras a cada uma dessas ''chains'', dependendo do policiamento de tráfego a ser implantado no firewall.
  
−
Hoje vamos continuar a [[RMU-2012-1#Atividade_2:_criando_uma_infraestrutura_com_m.C3.BAltiplos_servidores_Asterisk|atividade da semana passada]], em que se criou uma infraestrutura com múltiplos PBX Asterisk. Vamos incrementá-la implantando as seguintes melhorias:
 
−
# Execute uma máquina virtual Ubuntu Desktop, mas antes configure sua interface ethernet para operar em modo NAT.
 
−
# Instale o softphone [http://tele.sj.ifsc.edu.br/~msobral/soft/jitsi_1.0-latest_i386.deb Jitsi] nessa máquina virtual. Configure-o para usar o seu PBX.
 
−
# Execute o wireshark, e deixe-o capturando datagramas UDP em todas as interfaces de rede.
 
−
# Tente realizar uma chamada entre softphone e telefone IP. A chamada foi realizada ? O que mostrou o wireshark ?
 
−
# Configure o softphone e o telefone IP para usarem o servidor STUN instalado em 192.168.2.1.
 
−
# Tente novamente realizar uma chamada entre softphone e telefone IP. A chamada foi realizada ? O que mostrou o wireshark ?
 
  
−
<!-- # Cada dupla de alunos deve criar um domínio DNS próprio, e que seja subdomínio de ''rmu.sj.ifsc.edu.br''. O nome do subdomínio deve ser informado ao professor, para que seja adicionado ao servidor do domínio ''rmu.sj.ifsc.edu.br''.
+
[[imagem:Iptables-chains.png|400px]]
−
# Em seu subdomínio inclua um registro SRV para apontar seu PBX Asterisk.
 
−
-->
 
  
−
= 19/03: Prática com Asterisk: URA =
 
  
−
O que é uma URA (''Unidade de Resposta Audível'') ? Clique na imagem abaixo ...
+
Uma regra deve especificar basicamente três coisas:
 +
* '''Chain''': em que ''chain'' deve ser adicionada.
 +
* '''Seletor:''' informações a serem usadas para selecionar os pacotes a que ela deve ser aplicada.
 +
* '''Alvo (''target''):''' ação a ser executada sobre o pacote que ativar a regra.
  
−
[[imagem:Ura-tabajara.png|link=http://www.youtube.com/watch?v=VfDh2GhGnVg]]
+
Por exemplo, a regra abaixo permite o encaminhamento de todos os segmentos TCP destinados a porta 80:
−
<br>''URA Tabajara''
 
  
−
Uma URA implementa um menu audível para auto-atendimento. Sua construção é feita toda no plano de discagem, como se pode ver no exemplo abaixo:
 
  
−
<syntaxhighlight lang=text>
+
[[imagem:Iptables-intro.png]]
−
[default]
 
−
exten => 666,1,Goto(ura,s,1)
 
  
−
[ura]
 
−
exten => s,1,Answer
 
−
exten => s,2,NoOp(Ligação entrou na URA)
 
−
exten => s,n,Background(/var/lib/asterisk/sounds/benvindo)
 
−
exten => s,n,NoOp(Digite a opção/1-suporte/2-comercial/3-financeiro)
 
−
exten => s,n,WaitExten(6); caso nada tenha sido digitado durante a mensagem "benvindo", espera mais 6 segundos no máximo
 
  
−
exten => 1,1,NoOp(Chamada foi para Suporte)
+
Desta forma, a escrita das regras depende de conhecer as opções para definição de seletores, e os possíveis alvos. Algumas opções de uso comum para composição de  seletores são listadas abaixo, sendo que o que está entre colchetes ([]) é opcional. Um seletor pode ser composto por uma combinação dessas opções. Para mais detalhes leia o [http://manpages.ubuntu.com/manpages/natty/man8/iptables.8.html manual].
−
same => n,Dial(SIP/2402,60)
 
−
same => n, Hangup
 
  
−
exten => 2,1,NoOp(Chamada foi para Comercial)
+
{| border="1" cellpadding="2"
−
same => n,Dial(SIP/2801,60)
+
!Opção
−
same => n, Hangup
+
!Descrição
−
 
+
!Exemplo
−
exten => 3,1,NoOp(Chamada foi para Financeiro)
+
|-
−
same => n,Dial(SIP/2000,60)
+
| -s IP[/Mascara] || endereço IP de origem|| -s 200.135.37.64/26
−
same => n, Hangup
+
|-
−
 
+
| -d IP[/Mascara] || endereço IP de destino|| -d 8.8.8.8
−
exten => i,1,NoOp(Extensão inválida)
+
|-
−
same => n,Play(beep)
+
| -p Protocolo || protocolo de transporte (tcp ou udp) || -p tcp
−
same => n,GoTo(s,3); volta para o menu
+
|-
 +
| --dport numero || Port de destino || --dport 80
 +
|-
 +
| --sport numero || Port de origem || --sport 53
 +
|-
 +
| --syn || Se flag SYN está acesa (somente TCP) ||
 +
|-
 +
| --tcp-flags Flags1 Flags2 || Se somente as flags listadas em Flags1 estão acesas dentre as Flags2 || --tcp-flags SYN,ACK,RST,FIN SYN
 +
|-
 +
| -i interface || Se pacote foi recebido pela interface || -i eth0
 +
|-
 +
| -o interface || Se pacote vai sair pela interface || -o eth1
 +
|-
 +
| -m state --state ESTADO || Identifica o estado do fluxo, o qual pode ser:<br>NEW: início de um fluxo<br>ESTABLISHED: parte de um fluxo estabelecido<br>RELATED: inicia um novo fluxo, porém relacionado com um fluxo existente || -m state --state NEW,RELATED
 +
|}
  
−
exten => t,1,NoOp(Tempo esgotado)
 
−
same => n,Dial(SIP/3401,60)
 
−
same => n,Hangup
 
−
</syntaxhighlight>
 
  
−
A URA é composta por mensagens de voz, que instruem o usuário sobre o que ele pode fazer (isto é, apresentam as opções), e músicas, que o entreteem (!?) enquanto aguarda uma operação ser realizada. Assim, para criar uma URA minimamente funcional são necessários esses arquivos de voz. Para gravá-los, pode-se criar uma extensão especial que atenda por ''9005nome_de_um_arquivo''. Ao chamar essa estensão, pode-se pronunciar a mensagem de voz assim que o Asterisk atender. Para encerrar a mensagem, deve-se digitar ''#''. O arquivo de voz resultante estará no diretório ''/var/lib/asterisk/sounds'', ou em qualquer outro diretório especificado na aplicação ''record''.
+
Os alvos definem o que fazer com um pacote selecionado por uma regra. As ações possíveis estão listadas abaixo:
  
−
<syntaxhighlight lang=text>
 
−
exten=_9005.,1,answer()
 
−
exten=_9005.,n,record(/var/lib/asterisk/sounds/${EXTEN:4}.wav,5,t)
 
−
exten=_9005.,n,playback(/var/lib/asterisk/sounds/${EXTEN:4})
 
−
exten=_9005.,n,hangup()
 
−
</syntaxhighlight>
 
  
−
== Atividade ==
+
{| border="1" cellpadding="2"
−
 
+
!Alvo
−
# Crie a URA Tabajara, conforme o vídeo visto na aula.
+
!Descrição
−
# Crie uma URA que possibilite um usuário SIP mudar sua senha. Dica: veja as aplicações [http://www.voip-info.org/wiki/view/Asterisk+cmd+read Read] e [http://www.voip-info.org/wiki/view/Asterisk+cmd+System System] e a função [http://www.voip-info.org/wiki/view/Asterisk+func+shell SHELL].
+
!Exemplo
 +
|-
 +
| ACCEPT || aceita o pacote|| -j ACCEPT
 +
|-
 +
| DROP || descarta o pacocte || -j DROP
 +
|-
 +
| REJECT || rejeita o pacote, devolvendo um código de erro ICMP para seu remetente || -j REJECT
 +
|-
 +
|LOG || registra o pacote no log do sistema || -j LOG
 +
|-
 +
|uma_chain || passa o pacote para ser processado pela chain uma_chain || -j rede_interna
 +
|}
  
−
= 21/03: Trabalho Asterisk =
 
  
−
Uma empresa possui uma matriz e uma filial em outra cidade. As redes dessas unidades da empresa possuem ambas um link para Internet, sendo que seus roteadores fazem NAT. Para implementar os ramais telefônicos internos, optou-se por usar uma infraestrutura composta por um PBX Asterisk na matriz e outro na filial. Todos os ramais da empresa foram implantados com telefones IP ou telefones convencionais acoplados a um ATA. Por fim, o acesso a PSTN é realizado por um PBX proprietário capaz de falar o protocolo IAX2.
+
=== Salvando e restaurando regras do iptables ===
  
−
Implante essa estrutura, assumindo que o PBX com acesso a PSTN já existe, e possui IP 172.18.200.251. O tronco IAX2 com esse PBX deve ser autenticado com usuário ''EquipeXX'' e senha ''SenhaXX''. Além disso, a estrutura deve atender a estes requisitos:
+
Uma vez obtido um conjunto de regras que funcione como desejado, deve-se poder salvá-lo para que possa ser reativado sempre que desejado (ex: no boot). Existem dois utilitários que auxiliam nessa tarefa, sendo eles:
−
# O PBX da Matriz faz o tronco IAX2 com o PBX da PSTN.
+
* '''iptables-save''': escreve as regras atuais na saída padrão, que normalmente é redirecionada para um arquivo: <syntaxhighlight lang=bash>
−
# O tronco entre PBX da matriz e da filial pode ser SIP ou IAX2.
+
iptables-save > minhas_regras
−
# Ramais da empresa possuem três dígitos, sendo que ramais iniciados com dígitos 1 a 5 são da matriz, e 7 a 8 são da filial. O ramal 9 chama a telefonista, e o prefixo 0 direciona a chamada para a PSTN.
+
</syntaxhighlight>
−
# Existem duas telefonistas, que são selecionadas através de uma fila de atendimento no PBX da matriz.
+
* '''iptables-restore''': instala as regras lidas da entrada padrão, normalmente redirecionada de um arquivo: <syntaxhighlight lang=bash>
−
# Os ramais em cada unidade da empresa são divididos em: administração e produção. Ramais da produção podem fazer captura de chamadas somente entre si, mas os da administração podem fazer captura de todos os ramais.
+
iptables-restore < minhas_regras
−
# O ramal especial 6XX dá acesso ao SAC da empresa. Esse é feito inicialmente por uma URA, que deve oferecer um menu com as seguintes opções:
+
</syntaxhighlight>
−
## Dúvidas sobre produtos, que são encaminhadas ao setor de vendas.
 
−
## Clientes corporativos, que são encaminhadas ao setor de marketing.
 
−
## Outras necessidades, que são encaminhadas às telefonistas.
 
  
−
'''Orientações:'''
+
== Atividade ==
−
* O trabalho pode ser feito por equipes de dois alunos.
+
 
−
* A entrega do trabalho deve ser feita até o dia '''12/07'''.
+
Cada aluno deve implantar a seguinte rede virtual em seu computador:
−
* O trabalho deve ser demonstrado dentro do laboratório de Redes 2, estando os membros da equipe sujeitos a questionamentos.
+
 
−
* Deve ser entregue um relatório contendo uma explicação sobre como foram implementadas as características e funcionalidades da estrutura, incluindo as configurações que foram realizadas no Asterisk.
+
 
 +
[[imagem:Lab-firewall-intro.png]]
  
−
== Como criar a rede de desenvolvimento ==
 
  
−
A rede para desenvolver o trabalho pode ser feita com máquinas virtuais (VM) Virtualbox. Existem diferentes formas de configurar essas VM, sendo uma delas a mostrada abaixo:
+
O ''firewall'' e o ''Pc'' devem ser máquinas virtuais. Você pode usar o Virtualbox ou o [[Netkit]]. Se optar pelo segundo, use a seguinte configuração de rede (grave-a em um arquivo chamado ''Lab.conf''):
  
 +
<syntaxhighlight lang=text>
 +
# Obs: substitua X pelo número do seu computador
 +
pc[type]=generic
 +
firewall[type]=gateway
 +
#internet[type]=generic
  
−
[[imagem:Trab-asterisk.png]]
+
pc[eth0]=link:ip=10.1.X.1/24
 +
firewall[eth1]=link:ip=10.1.X.254/24
 +
firewall[eth0]=uplink:bridge=eth0:ip=192.168.2.100+X/24
 +
#firewall[eth0]=externo:ip=192.168.2.100+X/24
 +
#internet[eth0]=externo:ip=192.168.2.1/24
  
 +
pc[default_gateway]=10.1.X.254
 +
firewall[default_gateway]=192.168.2.1
 +
#internet[default_gateway]=192.168.2.100+x/24
 +
</syntaxhighlight>
  
−
# Crie duas VM (uma para cada servidor Asterisk). Cada VM deve ter uma interface em modo NAT.
+
No caso do [[Netkit]], execute o programa '''gnome-netkit''' para executar a rede virtual. Selecione o menu ''File->Load and run'' e carregue o arquivo ''Lab.conf''.
−
# Na VM ''matriz'' faça o seguinte:
+
 
−
## Instale o Ubuntu Desktop 10.04 LTS ou superior (no laboratório pode ser usada a VM Ubuntu-grafico).
+
Se for usado o Virtualbox, use a máquina virtual ''Rmu-server'' para ser o firewall, e ''Rmu-cliente''  para ser o Pc. Inicie-as, certificando-se de que suas interfaces de rede estejam em modo bridge. Configure os endereços IP de suas interfaces e também suas rotas default.
−
## Instale os seguintes softwares com apt-get: asterisk, openjdk-6-headless-jre libxalan2-java
+
 
−
## Certifique-se de que o conteúdo do arquivo /etc/network/interfaces esteja assim: <syntaxhighlight lang=text>
+
=== DICA ===
−
auto lo eth0
 
  
−
iface lo inet loopback
+
É útil ativar o NAT na interface externa do firewall (eth0 na nossa rede de teste):
  
−
iface eth0 inet dhcp
+
<syntaxhighlight lang=bash>
 +
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
 
</syntaxhighlight>
 
</syntaxhighlight>
−
## Após reiniciar a VM, obtenha o [http://tele.sj.ifsc.edu.br/~msobral/soft/jitsi_1.0-latest_i386.deb Jitsi] e instale-o assim: <syntaxhighlight lang=bash>
 
−
sudo dpkg -i jitsi_1.0-latest_i386.deb
 
−
</syntaxhighlight>
 
−
## Faça um clone do disco virtual dessa VM, executando o seguinte comando: <syntaxhighlight lang=bash>
 
−
vboxmanage clonehd disco_da_vm.vdi disco_da_vm2.vdi
 
−
</syntaxhighlight>...sendo que ''disco_da_vm.vdi'' é o pathname do disco virtual da VM que você preparou (no caso do laboratório, é /home/vms/ubuntu-grafico.vdi), e ''disco_da_vm2.vdi'' será a cópia desse disco. A cópia será usada para criar a VM ''filial''.
 
−
# Crie a VM ''filial''. Porém ao invés de criar um novo disco virtual, selecione o disco clonado da matriz.
 
−
 
−
== Como criar o tronco IAX2 ==
 
  
−
Para criar o tronco IAX2 com o Asterisk PSTN, insira a seguinte configuração em /etc/asterisk/iax.conf:
+
=== Cenário 1: Uma rede pequena sem servidores ===
 +
 
 +
Em uma rede pequena e que não oferece serviços, todos os fluxos se originam internamente. Assim, o firewall deve impor que somente fluxos internos possam passar. Com base nisso, configure seu firewall das seguintes formas:
 +
# ''Caso 1:'' os computadores internos podem acessar qualquer serviço externo.
 +
#* Com filtro ''stateless'': <syntaxhighlight lang=bash>
 +
# As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall
 +
 
 +
# Por default, bloqueia tudo
 +
iptables -P FORWARD DROP
 +
 
 +
# Libera todos pacotes TCP que entrarem pela interface eth1
 +
iptables -A FORWARD -i eth1 -p tcp -j ACCEPT
 +
 
 +
# Libera pacotes UDP destinados a porta 53 (DNS), contanto que tenham entrado pela interface eth1
 +
iptables -A FORWARD -i eth1 -p udp --dport 53 -j ACCEPT
 +
 
 +
# Libera pacotes UDP com port de origem 53 (resposta do DNS), contanto que tenham entrado pela interface eth0
 +
iptables -A FORWARD -i eth0 -p udp --sport 53 -j ACCEPT
 +
 
 +
# Libera segmentos TCP vindos pela interface eth0 e que tenham as flags SYN e ACK acesas (resposta de pedido de conexão TCP)
 +
iptables -A FORWARD -i eth0 -p tcp --tcp-flags SYN,ACK SYN,ACK -j ACCEPT
 +
 
 +
 
 +
# Libera segmentos TCP vindos pela interface eth0 e que não tenham a flags SYN acesa (pertencem a conexões estabelecidas)
 +
iptables -A FORWARD -i eth0 -p tcp ! --syn -j ACCEPT
 +
 
 +
</syntaxhighlight>
 +
#* Com filtro ''stateful'': <syntaxhighlight lang=bash>
 +
# As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall
 +
 
 +
# Libera todos pacotes de fluxos estabelecidos
 +
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
 +
 
 +
# Libera pacotes que iniciem novos fluxos, originados na rede interna (interface eth1)
 +
iptables -A FORWARD -i eth1 -m state --state NEW -j ACCEPT
 +
 
 +
# Regra default eh descartar
 +
iptables -P FORWARD DROP
 +
</syntaxhighlight>
 +
# ''Caso 2:'' os computadores internos podem acessar somente serviços Web e DNS. <!-- <syntaxhighlight lang=bash>
 +
# As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall
 +
 
 +
# Libera todos pacotes de fluxos estabelecidos
 +
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
 +
 
 +
# Libera datagramas UDP destinados a porta 53 (DNS), contanto que tenham se originado na rede interna
 +
iptables -A FORWARD -i eth1 -p udp --dport 53 -m state --state NEW -j ACCEPT
 +
 
 +
# Libera segmentos TCP destinados as portas 80 (HTTP) e 443 (HTTPS), contanto que tenham se originado na rede interna
 +
iptables -A FORWARD -i eth1 -p tcp --dport 80 -m state --state NEW -j ACCEPT
 +
iptables -A FORWARD -i eth1 -p tcp --dport 443 -m state --state NEW -j ACCEPT
 +
 
 +
# Descarta demais pacotes
 +
iptables -A FORWARD -j DROP</syntaxhighlight> -->
 +
#* Versão alternativa, usando o módulo ''multiport'': <!-- <syntaxhighlight lang=bash>
 +
# As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall
 +
 
 +
# Libera todos pacotes de fluxos estabelecidos
 +
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
 +
 
 +
# Libera datagramas UDP destinados a porta 53 (DNS), contanto que tenham se originado na rede interna
 +
iptables -A FORWARD -i eth1 -p udp --dport 53 -m state --state NEW -j ACCEPT
 +
 
 +
# Libera segmentos TCP destinados as portas 80 (HTTP) e 443 (HTTPS), contanto que tenham se originado na rede interna
 +
iptables -A FORWARD -i eth1 -p tcp -m multiport  --dports 80,443 -m state --state NEW -j ACCEPT
 +
 
 +
# Descarta demais pacotes
 +
iptables -A FORWARD -j DROP</syntaxhighlight> -->
 +
# ''Caso 3:'' os computadores internos podem acessar qualquer serviço, com exceção de redes eDonkey (ex: emule) e torrent.
 +
 
 +
= 26/02: Firewall =
 +
 
 +
Realização dos exercícios da aula de [[RMU-2012-2#21.2F02:_Firewall|21/02]], mais este aqui:
 +
 
 +
== Atividade ==
 +
 
 +
Na rede dos exercícios, inicie uma chamada VoIP entre o PC e o computador do professor (192.168.2.1). Essa chamada deve ser simulada com o ''siprtp'':
 +
 
 +
<syntaxhighlight lang=bash>
 +
siprtp --ip-addr=10.1.X.1 sip:0@192.168.2.1
 +
</syntaxhighlight>
 +
 
 +
Configure seu filtro de pacotes para que essa chamada possa ser realizada a contento.
 +
 
 +
== TAREFA: Leitura da semana ==
 +
 
 +
Leiam [https://www.google.com.br/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&ved=0CE4QxQEwBA&url=https%3A%2F%2Fdocs.google.com%2Fviewer%3Fa%3Dv%26q%3Dcache%3AjefcY_TMJ9MJ%3Awww.f5.com%2Fpdf%2Fwhite-papers%2Fltm-firewall-wp.pdf%2B%26hl%3Den%26gl%3Dbr%26pid%3Dbl%26srcid%3DADGEESjD3zuaRYVj7N0qaiGgd6VZnuwnpjbQa0Rmn0kOVPuLwoERfvPV-ohfizHOownneB9NafvVwPlTOM0Yo83nBRFxVUGYq3_ZWHza9c0-gdhayec0p7i3Hwn9j6vBhlKbZEMuwuCw%26sig%3DAHIEtbTB8tXeKNPNQyE3PH_Mf4mTaNrsSw&ei=47YsUa3vJu650AHC_4DYDg&usg=AFQjCNGHtQ2UKbmrZnHe1fBE4fSQFf7NFg este texto sobre modelos de firewalls e suas limitações], e preparem-se para apresentá-lo na aula de 05/03. Leiam as seções "Introduction" e "Firewall Limitations" (o restante é propagando de um produto).
 +
 
 +
= 28/02: Firewall =
 +
 
 +
... continuação dos exercícios da aula anterior.
 +
 
 +
= 05/03: Firewall =
 +
 
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-08.pdf Transparências]
 +
 
 +
* Projetos de firewalls (ver transparências)
 +
** Estratégias de implantação de firewalls
 +
** Perímetro de segurança
 +
** Tradução de endereços (NAT) - [http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html Anatomia de Tradutores NAT]
 +
 
 +
 
 +
'''Fluxo de processamento do Netfilter:'''
 +
 
 +
[[imagem:Iptables-fluxograma.png|800px]]
 +
 
 +
 
 +
== Dicas para NAT ==
 +
 
 +
* Fazendo NAT de todo o tráfego que sai pela interface eth0: <syntaxhighlight lang=bash>
 +
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
 +
</syntaxhighlight>
 +
* Fazendo NAT estático, de forma a associar um determinado IP externo a um IP interno (obs: eth0 é a interface externa): <syntaxhighlight lang=bash>
 +
iptables -t nat -A POSTROUTING -o eth0 -s IP_interno -j SNAT --to-source IP_externo
 +
</syntaxhighlight>
 +
* Redirecionando um pacote para outro IP e/ou port: <syntaxhighlight lang=bash>
 +
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 2200 -j DNAT --to-destination IP_interno:22
 +
</syntaxhighlight>
 +
 
 +
== Ativando e desativando as regras do filtro IP (iptables) ==
 +
 
 +
O seguinte script, que deve ser salvo com o nome ''firewall.sh'', pode ser usado para ativar e desativar as regras do filtro IP:
 +
 
 +
<syntaxhighlight lang=bash>
 +
#!/bin/bash
 +
# Variaveis
 +
DEV_LAN=eth0
 +
DEV_WAN=eth1
 +
 
 +
fw_start(){
 +
  # Adicionando regras
 +
  iptables -A INPUT -i $DEV_LAN -j ACCEPT
 +
}
 +
 
 +
fw_stop(){
 +
  # Limpando as regras
 +
  iptables -P INPUT ACCEPT
 +
  iptables -t filter -F
 +
  iptables -t nat -F
 +
}
 +
 
 +
fw_uso(){
 +
  # Mensagem de ajuda
 +
  echo "Sintaxe errada..."
 +
  echo "./$0 (start|stop)"
 +
}
 +
 
 +
case $1 in
 +
  start)
 +
    fw_start
 +
    ;;
 +
  stop)
 +
    fw_stop
 +
    ;;
 +
  *)
 +
    fw_uso
 +
    ;;
 +
esac
 +
</syntaxhighlight>
 +
 
 +
* Iniciando o firewall: <syntaxhighlight lang=bash>
 +
./firewall.sh start
 +
</syntaxhighlight>
 +
* Parando o firewall: <syntaxhighlight lang=bash>
 +
./firewall.sh stop
 +
</syntaxhighlight>
 +
* Obtendo informações sobre seu uso: <syntaxhighlight lang=bash>
 +
./firewall.sh
 +
</syntaxhighlight>
 +
 
 +
== Atividade 1: firewall/roteador para rede doméstica ==
 +
 
 +
Uma pequena rede possui um firewall com algumas regras básicas para protegê-la do mundo externo:
 +
* Política padrão: '''negar tudo''' (entrada e roteamento)
 +
* Usuários da rede local só podem navegar na web, acessar email (POP3, IMAP, SMTP)
 +
* Firewall pode ser administrado remotamente via SSH, não importando a origem da conexão.
 +
** Para dificultar ataques por varredura de portas, o servidor SSH deve atender conexões em uma porta diferente da 22.
 +
* Registrar todas conexões oriundas da rede externa
 +
 
 +
== Atividade 2: serviço SMTP rodando em rede com NAT ==
 +
 
 +
[[imagem:Fw-lab3.png]]
 +
 
 +
 
 +
* Política padrão: '''negar tudo''' (entrada e roteamento)
 +
* Permitir pings a uma taxa máxima de 10 pacotes por minuto
 +
* Tráfego destinado à porta TCP 25 deve ser encaminhado para a porta 25 do computador M1 (192.168.2.1) da rede local
 +
** Isso se destina impedir que máquinas da rede local gerem SPAM através de conexões diretas a servidores SMTP externos
 +
* Tanto o firewall quanto a máquina ''pc'' podem ser administradas remotamente via SSH.
 +
 
 +
Obs: para monitorar quantos pacotes estão casando com as regras:
 +
<syntaxhighlight lang=bash>
 +
watch iptables -t filter -L -v
 +
</syntaxhighlight>
 +
 
 +
Obs: para limitar a taxa de pacotes deve-se usar o módulo ''limit'' (ver maiores detalhes no [http://manpages.ubuntu.com/manpages/natty/man8/iptables.8.html manual]). Por exemplo:
 +
<syntaxhighlight lang=bash>
 +
# limita as cconexões ao servidor web: no máximo 2 por segundo
 +
iptables -A FORWARD -p tcp -m limit -m multiport -m state -d IP_servidor_web --dports 80,443
 +
--state NEW --limit-rate 2/second -j ACCEPT
 +
</syntaxhighlight>
 +
 
 +
{{collapse top | Configuração para Netkit}}
 +
<syntaxhighlight lang=text>
 +
# Obs: substitua X pelo número do seu computador
 +
pc[type]=generic
 +
firewall[type]=gateway
 +
 +
pc[eth0]=link:ip=10.1.X.1/24
 +
firewall[eth1]=link:ip=10.1.X.254/24
 +
firewall[eth0]=uplink:bridge=eth0:ip=192.168.2.100+X/24
 +
 +
pc[default_gateway]=10.1.X.254
 +
firewall[default_gateway]=192.168.2.1
 +
</syntaxhighlight>
 +
{{collapse bottom}}
 +
 
 +
{{collapse top | Exemplo de regras}}
 +
<syntaxhighlight lang=bash>
 +
#!/bin/bash
 +
 
 +
# Variaveis
 +
DEV_LAN=eth1
 +
DEV_WAN=eth0
 +
 +
fw_start(){
 +
  # Adicionando regras
 +
  iptables -P FORWARD DROP
 +
 
 +
  iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
 +
  iptables -A FORWARD -i $DEV_LAN -p tcp --dport 25 -m state --state NEW -j ACCEPT
 +
  iptables -A FORWARD -i $DEV_LAN -p tcp --dport 80 -m state --state NEW -j ACCEPT
 +
  iptables -A FORWARD -i $DEV_LAN -p tcp --dport 443 -m state --state NEW -j ACCEPT
 +
  iptables -A FORWARD -i $DEV_LAN -p udp --dport 53 -m state --state NEW -j ACCEPT
 +
  iptables -A FORWARD -i $DEV_LAN -p icmp -m state --state NEW -j ACCEPT
 +
  iptables -A FORWARD -i $DEV_WAN -p tcp --dport 22 -d 10.1.1.1 -m state --state NEW -j ACCEPT
 +
  iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
 +
 
 +
  # NAT
 +
  iptables -t nat -A POSTROUTING -o $DEV_WAN -j MASQUERADE
 +
 
 +
  # Redirecionamentos ...
 +
  iptables -t nat -A PREROUTING -i $DEV_LAN -p tcp --dport 25 -j DNAT --to-destination 192.168.2.1
 +
  iptables -t nat -A PREROUTING -i $DEV_WAN -p tcp --dport 2200 -j DNAT --to-destination 10.1.1.1:22
 +
 
 +
}
 +
 +
fw_stop(){
 +
  # Limpando as regras
 +
  iptables -P INPUT ACCEPT
 +
  iptables -t filter -F
 +
  iptables -t nat -F
 +
}
 +
 +
fw_uso(){
 +
  # Mensagem de ajuda
 +
  echo "Sintaxe errada..."
 +
  echo "./$0 (start|stop)"
 +
}
 +
 +
case $1 in
 +
  start)
 +
    fw_start
 +
    ;;
 +
  stop)
 +
    fw_stop
 +
    ;;
 +
  *)
 +
    fw_uso
 +
    ;;
 +
esac
 +
</syntaxhighlight>
 +
{{collapse bottom}}
 +
 
 +
== TAREFA: Leitura da semana ==
 +
 
 +
Leiam [http://www.sans.org/reading_room/whitepapers/firewalls/intrusion-detection-response-leveraging-generation-firewall-technology_33053 este texto sobre firewalls de nova geração], e se preparem para apresentá-lo na aula de 12/03. Leiam as seções 1 a 4 (se quiserem ler todo o resto, fiquem à vontade ;-).
 +
 
 +
= 07/03: Lista de exercícios: Firewall =
 +
 
 +
Nesta aula a turma se organizará em grupos, que devem resolver o seguinte problema:
 +
 
 +
[[imagem:Fw-lista1.png]]
 +
 
 +
 
 +
A rede acima é composta de dois segmentos, ambos implantados com subredes IP com endereços não roteáveis:
 +
* '''DMZ:''' contém servidores que podem sere acessados a partir da rede externa.
 +
* '''Rede interna:''' contém computadores que não podem ser acessados de fora.
 +
 
 +
Crie as regras do filtro IP no firewall para que os serviços indicados nos servidores da DMZ possam ser acessados de fora. Essas regras devem também permitir o acesso irrestrito dos computadores da rede interna à Internet (ex: o Pc). Os servidores da DMZ, por sua vez, não podem iniciar conexões - seja para a rede interna ou externa. Além disso, o firewall deve poder ser administrado remotamente via SSH. Por fim, devem ser registrados todos os inícios de conexões e todos os pacotes recusados.
 +
 
 +
Obs: quem quiser fazer o exercício com o [[Netkit]] pode usar o seguinte modelo para a rede:
 +
 
 +
<syntaxhighlight lang=text>
 +
global[compact]=1
 +
dmz1[type]=generic
 +
dmz2[type]=generic
 +
pc[type]=generic
 +
firewall[type]=gateway
 +
 +
# Um computador pode ser usado para representar a Internet (!?!)
 +
internet[type]=generic
 +
 +
dmz1[eth0]=dmz:ip=10.0.0.1/24
 +
dmz2[eth0]=dmz:ip=10.0.0.2/24
 +
firewall[eth1]=dmz:ip=10.0.0.254/24
 +
 +
pc[eth0]=lan-interna:ip=192.168.0.1/24
 +
firewall[eth2]=lan-interna:ip=192.168.0.254/24
 +
 +
firewall[eth0]=link-internet:ip=172.18.0.100/16
 +
 +
# A "Internet" tem só o IP 172.18.0.1 ;-)
 +
internet[eth0]=link-internet:ip=172.18.0.1/16
 +
 +
dmz1[default_gateway]=10.0.0.254
 +
dmz2[default_gateway]=10.0.0.254
 +
 +
pc[default_gateway]=192.168.0.254
 +
 
 +
# Se o script firewall.sh ficar em /root, ele pode ser preservado para poder ser usado
 +
# em proximas execucoes da rede virtual. Porém para isso deve-se exportar
 +
firewall[preserve]=/root/firewall.sh
 +
</syntaxhighlight>
 +
 
 +
== Estendendo as regras do firewall ==
 +
 
 +
Na rede do exercício sobre firewall, algumas novas regras de policiamento de tráfego devem ser implantadas:
 +
* '''DMZ:'''
 +
** O servidor SMTP deve poder enviar mensagens para fora.
 +
** O servidor WWW pode ser acessado via FTP. As portas a serem usadas no modo passivo vão de 30000 a 30200.
 +
* '''Rede interna:'''
 +
** Acesso a web deve ser feito obrigatoriamente por meio de um proxy que roda no firewall. Esse proxy atende na porta TCP 3128.
 +
** Envio de email somente pode ser feito por meio do servidor SMTP que está na DMZ.
 +
** Programas de chat devem ser bloqueados (ex: MSN, Jabber, Skype).
 +
 
 +
<!-- == Documento a ser entregue ==
 +
 
 +
Apresentar um shell script (comentado) com as funções ''start'', ''stop'', ''restart'' e ''uso'' com as devidas regras para implementação do firewall e roteador. Faça uso de variáveis para os endereços IP, endereços de rede, interfaces de rede, etc. visando assim tornar o script mais genérico.
 +
-->
 +
 
 +
<!-- == Lista de exercícios ==
 +
 
 +
Resolver os exercícios e problemas propostos no capítulo 7 do livro ''Redes de Computadores e a Internet, 5a edição'', de James Kurose. Em particular, resolver:
 +
* '''Exercícios de fixação:''' todos
 +
* '''Problemas:''' 1, 3, 4, 5, 7, 9, 10, 11, 20, 21, 22, 23, 24, 25, 26, 27, 28
 +
-->
 +
 
 +
= 12/03: Projeto final =
 +
 
 +
O projeto final de RMU trata da implantação de uma rede corporativa composta por uma matriz e uma filial. Ambas unidades da empresa possuem suas próprias redes, que possuem um link para uma operadora de longa distância. A empresa usa essa infraestrutura de rede para aplicações corporativas entre matriz e filial (incluindo ERP e VoIP), e para acesso a Internet.
 +
 
 +
A turma deve se dividir em 04 equipes. Cada equipe deve implantar sua rede corporativa de forma a atender estes requisitos:
 +
* '''Serviço telefônico dentro da empresa deve ser feito com VoIP:'''
 +
* '''Os diferentes tipos de tráfego devem ter seus requisitos de QoS atendidos:'''
 +
* '''As comunicações dos usuários devem ser policiadas:'''
 +
 
 +
[[imagem:Proj-2012-2.png]]
 +
 
 +
== Detalhamento ==
 +
 
 +
O trabalho será feito usando o [[Netkit]] (versão 1.80 ou superior), pois do contrário seriam necessários dois computadores e pelo menos 5 VM Virtualbox. O Asterisk foi portado para o Netkit, porém somente com canais IAX2 e SIP. Como softphone deve ser usado o ''siprtp'' para simular chamadas VoIP.
 +
* [[Netkit#PBX_IP_.28Asterisk.29|Como usar o Asterisk dentro do Netkit]]
 +
 
 +
'''OBS:''' Os links PPPoE entre AC e os Firewalls têm taxa de downstream de 1 Mbps, e de upstream de 400 kbps. Isso já está implantado na configuração do experimento.
 +
 
 +
'''Requisitos:'''
 +
* As redes usam NAT para acessar a Internet.
 +
* Por default, tudo está bloqueado.
 +
* Chamadas VoIP têm prioridade a todos demais tipos de tráfego, porém limitadas a até duas chamadas VoIP simultâneas.
 +
* Tráfego de aplicações corporativas têm prioridade em relação a tráfego com a Internet.
 +
* Chamadas VoIP podem ser feitas somente entre telefones IP da empresa.
 +
* Em cada rede da empresa pode haver dois ou mais telefones IP.
 +
* O servidor ''intranet'' pode ser acessado da Internet para serviço Web (protocolos HTTP e HTTPS nas portas padrões).
 +
* Firewall da matriz pode ser acessado da Internet com SSH.
 +
* Firewall da filial pode ser acessado com SSH, porém somente a partir do Firewall da matriz.
 +
* Usuários das redes da empresa podem acessar qualquer serviço da Internet baseado em TCP. Serviços baseados em UDP não são permitidos.
 +
* Os Firewalls rodam servidores DNS, e assim os usuários das redes da empresa somente podem fazer consultas DNS aos Firewalls.
 +
* Protocolo ICMP está liberado, porém pings estão limitados a mensagens de 100 bytes e a taxas de até 2 mensagens por segundo.
 +
* O Gateway + Firewall da rede da esquerda PODE ser também um proxy SIP.
 +
 
 +
{{collapse top | Configuração da rede para o Netkit}}
 +
<syntaxhighlight lang=text>
 +
# Rede da Matriz:
 +
# - rede dos usuarios: 192.168.50.0/24
 +
# - DMZ: 192.168.100.0/24
 +
# Rede da Filial: 192.158.5.0/24
 +
#
 +
# Global attributes: these values are obtained automatically from menu General->Preferences
 +
global[compact]=True
 +
global[mem]=32
 +
#
 +
pbx[type]=pbx
 +
pc1[type]=generic
 +
fone1[type]=generic
 +
pc2[type]=generic
 +
fone2[type]=generic
 +
ac[type]=pppoe
 +
fw1[type]=gateway
 +
fw2[type]=gateway
 +
intranet[type]=generic
 +
internet[type]=generic
 +
 
 +
# O AC PPPoE, que prove links PPPoE com 1 Mbps de downstream
 +
ac[pppoe]=RMU:interface=eth0:users=(aluno1,senha1),(aluno2,senha2):range=192.168.10.1,192.168.10.10:ip=192.168.10.254:rate=1000
 +
ac[eth0]=adsl
 +
ac[eth1]=link:ip=192.168.1.10/24
 +
 
 +
# isto simula a internet ;-)
 +
internet[eth0]=link:ip=192.168.1.1/24
 +
internet[route]=192.168.0.0/16:gateway=192.168.1.10
 +
 
 +
# Os firewalls ... os links PPPoE tem 400kbps de upstream
 +
fw1[eth0]=adsl:mode=pppoe:pppoe_user=aluno1:pppoe_password=senha1:pppoe_ac=RMU:rate=400
 +
fw2[eth0]=adsl:mode=pppoe:pppoe_user=aluno2:pppoe_password=senha2:pppoe_ac=RMU:rate=400
 +
 
 +
# A rede da filial
 +
fw1[eth1]=filial:ip=192.168.5.254/24
 +
fw1[preserve]=/root/firewall.sh
 +
pc1[eth0]=filial:ip=192.168.5.1/24
 +
fone1[eth0]=filial:ip=192.168.5.2/24
 +
pc1[default_gateway]=192.168.5.254
 +
fone1[default_gateway]=192.168.5.254
 +
 
 +
# A rede da matriz
 +
fw2[eth1]=matriz:ip=192.168.50.254/24
 +
fw2[eth2]=dmz:ip=192.168.100.254/24
 +
fw2[preserve]=/root/firewall.sh
 +
pc2[eth0]=matriz:ip=192.168.50.1/24
 +
fone2[eth0]=matriz:ip=192.168.50.2/24
 +
intranet[eth0]=dmz:ip=192.168.100.2/24
 +
pc2[default_gateway]=192.168.50.254
 +
fone2[default_gateway]=192.168.50.254
 +
intranet[default_gateway]=192.168.100.254
 +
intranet[services]=apache2:ssh
 +
 
 +
# O PBX Asterisk
 +
pbx[eth0]=dmz:ip=192.168.100.1/24
 +
pbx[default_gateway]=192.168.100.254
 +
pbx[preserve]=/usr/local/asterisk/etc
 +
</syntaxhighlight>
 +
{{collapse bottom}}
 +
 
 +
 
 +
<!-- * Cada equipe deve usar um tipo de firewall. As opções são:
 +
** [http://www.zeroshell.org/ ZeroShell]
 +
** [http://www.pfsense.org/ pfSense]
 +
** [http://www.brazilfw.com.br/forum/ BrazilFw]
 +
** [http://www.shorewall.net/ Shorewall]
 +
** [http://www.endian.com/en/community/overview/ Endian UTM Appliance]
 +
** [http://www.ipfire.org/ IPFire]
 +
** [http://ipcop.org/ IPCop]
 +
-->
 +
 
 +
'''Data de entrega: ''' até 21/03/2013
  
−
<syntaxhighlight lang=text>
+
= 14/03: Apresentação de TCC 1 =
−
[EquipeXX]
 
−
type=friend; pode iniciar e receber chamadas
 
−
username=EquipeXX; identidade do asterisk da outra ponta do canal
 
−
context=seu_contexto; contexto em que processa chamadas recebidas
 
−
callerid="PBX EquipeXX"
 
−
secret=SenhaXX; senha para autenticar a chamada (iniciadas e recebidas)
 
−
host=172.18.200.251; endereço IP do asterisk na outra ponta do tronco
 
−
peercontext=rmu; contexto que deve processar a chamada no asterisk destino
 
−
</syntaxhighlight>
 
  
−
No plano de discagem você deve encaminhar chamadas por esse canal IAX2. Por exemplo, se quiser chamar o número 33812850, a aplicação ''Dial'' no plano de discagem deve ser invocada assim:
+
Todos convidados ...
  
−
<syntaxhighlight lang=text>
+
= 20/03: Avaliação 3 =
−
exten=>33812850,1,Dial(IAX2/EquipeXX/033812850)
 
−
</syntaxhighlight>
 
  
−
Note que esse exemplo deve ser adaptado no seu plano de discagem para que fique genérico, possibilitando chamar qualquer número da PSTN através desse canal IAX2.
+
* Disciplinas de filas
 +
* Modelos de QoS para Internet (Diffserv e Intserv)
 +
* Firewalls
  
−
=== Tronco IAX2 entre matriz e filial ===
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/ex-prova1-2012-1.pdf Questões usadas em 2012-1]
  
−
Esse tronco pode ser criado de forma muito parecida com o tronco entre matriz e Asterisk PSTN. Basta acrescentar em ''/etc/asterisk/iax.conf'' a configuração do novo tronco:
+
= 21/03: Apresentação do projeto =
−
 
 
−
<syntaxhighlight lang=text>
 
−
[matriz-filial]; nome da seção, o qual identifica o canal IAX2
 
−
type=friend
 
−
username=matriz-filial; note que isso deve ser igual ao nome da seção
 
−
context=seu_contexto
 
−
callerid="PBX Matriz_ou_Filial"
 
−
secret=Sua_Senha
 
−
host=IP_da_matrix_ou_filial
 
−
peercontext=contexto_destino
 
−
qualify=yes
 
−
</syntaxhighlight>
 
−
 
 
−
= ??/??: Trabalho Asterisk =
 
−
 
 
−
= ??/??: Avaliação: Prova 2 =
 
−
 
 
−
A avaliação será sobre protocolos de tempo-real e modelo SIP:
 
−
* [[RMU-2012-1#17.2F05:_Protocolos_de_Tempo-Real|Protocolos RTP e RTCP]]
 
−
* [[RMU-2012-1#24.2F05:_SIP|Protocolo SIP]]
 
−
* Estabelecimento de chamadas envolvendo esses protocolos
 
−
 
 
−
Além da wiki, há um bom resumo nas transparências:
 
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-22.pdf VoIP]
 
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-25.pdf Asterisk]
 
−
 
 
−
A lista de exercícios abaixo se refere aos [http://tele.sj.ifsc.edu.br/~msobral/rmu/exercicios.zip problemas do capítulo 7] do livro ''Redes de Computadores e a Internet, 5a edição'', de James Kurose:
 
−
* '''Problemas:''' 4, 15, 16, 17, 19
 
−
 
 
−
No livro ''Comunicação de Dados e Redes de Computadores, 4a edição'', de Behrouz Forouzan há um resumo sobre esse assunto. Apesar de estar muito simplificado, ainda mais se comparado ao livro do Kurose, pode ser útil como leitura adicional:
 
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/rtp-sip.pdf RTP e VoIP (Forouzan)]
 
−
 
 
−
 
 
−
Vejam as provas feitas em semestres anteriores:
 
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/prova2-2011-2.pdf 2011-2]
 
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/prova2-rec-2011-2.pdf 2011-2 (recuperação)]
 
  
−
= ??/??: Apresentação do trabalho =
+
No laboratório ...
  
−
... e a recuperação ficou para o início de agosto (a combinar).
+
= 22/03: Recuperação =

Edição atual tal como às 15h48min de 14 de outubro de 2015

Redes Multimidia: Diário de Aula 2012-2

Professor: Marcelo Maia Sobral
Lista de email (forum): rmu-ifsc@googlegroups.com
Encontros: 3a feira/13:30, 5a feira/15:40
Atendimento paralelo: 3a de 10:00 às 11:00 h

Bibliografia

  • Livros sobre Redes de Computadores (por ordem de preferência):
    • KUROSE, James F. e ROSS, Keith W. Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição. Editora Addison Wesley SP, 2010.
    • Sérgio Colcher, Antônio Tadeu Azevedo Gomes, e Anderson Oliveira da Silva. VoIP: Voz sobre IP. Campus, 1a edição, 2005.
    • STALLINGS, W. Redes e sistemas de comunicação de dados. Editora Elsevier RJ, 2005.
    • TANENBAUM, Andrew S. Redes de Computadores, tradução da quarta edição. Editora Campus RJ, 2003
    • FOROUZAN, Behrouz. Comunicação de Dados e Redes de Computadores, 3a/4a edicão. Editora Bookman, 2004.

Curiosidades

Listas de exercícios

Avaliações

Aluno 1a prova 2a prova 3a prova Trabalho VoIP Trabalho Firewalls FINAL
Ana Paula C C C C ? I
André B A B A C B
Emanuel D*/D B D/D D* ? D
Fabiano C C D/B C ? I
Kalvim C B B C B B
Leandro D B D C ? D
Liamari D D D C ? D
Luiz Gustavo C C B A C C
Maicky C D/D D*/D A C D
Marine D/C C D*/D C ? D
Mário D/B C C A B B

Obs: D* = não fez a avaliação.

Softwares

04/10: Apresentação

Apresentação da disciplina: conteúdo, bibliografia e avaliação, laboratório.

Redes multimidia

Uso de redes de dados para transmitir conteúdo de diferentes midias:

Algumas questões sobre essas aplicações:

  1. Como funcionam esses serviços ? Como os conteúdos são acessados ?
  2. Como os dados são representados ?
  3. Como os dados são transportados através da rede ? Quais os protocolos envolvidos e como os dados são encapsulados em suas PDUs ?
  4. Que requisitos quanto à transmissão pela rede possuem para um bom funcionamento ?

Exemplo 1: video streaming

Video streaming é a transmissão de video por uma rede de dados, com sua visualização ocorrendo à medida que for sendo recebido pelo cliente. Um exemplo muito conhecido de serviço de video streaming é fornecido pelo YouTube. Outros exemplos de video streaming são Netflix, que possibilita assistir filmes via Internet mediante o pagamento de uma assinatura, e a transmissão de jogos de futebol via Internet por algumas emissoras de TV aberta. Apesar de a experiência dos usuários parecer a mesma (ou quase ...) para esses serviços, existem diferenças na forma como são implementados.


Experimente visualizar os videos abaixo. Em todos eles observe quanto tempo demora para iniciar a tocar o video e sua continuidade (se ele interrompe ou degrada a imagem). Experimente também avançar o video, como por exemplo para perto de seu final.

Como é feito o acesso a esses videos, e como eles são transportados pela rede ?

  • Execute o wireshark e repita o acesso aos videos. Enquanto a captura acontece, faça um reposicionamento do video - i.e. avance-o para perto de seu final. Observe as mensagens trocadas entre sua aplicação cliente e o servidor do video.
  • Você conseguiria descrever como funcionam seus acessos e tranmsmissões ?
  • Você pode notar alguma diferença entre as diferentes formas de transmissão do video ?

Exemplo 2: Internet radio

Atualmente muitas estações de rádio transmitem suas programações também pela Internet. Existem inclusive muitas estações cujas transmissões são feitas somente pela rede - i.e. a rigor, não fazem transmissão por rádio. Com isso, pessoas conseguem escutar a programação de uma estação de rádio de outro país. Um atrativo dessas estações via Internet é informarem o gênero de música transmitida, além de apresentarem uma boa qualidade sonora. Esse tipo de serviço se popularizou tanto que existem diretórios de estações, que podem ser acessados por aplicativos e assim possibilitar que os usuários escolham que tipo de música desejam escutar.

Um aplicativo do Linux que oferece fácil acesso a Internet radio é o Rhytmbox. Ele pode ser executado no menu Aplicativos->Som e video. Execute o Rhytmbox em seu computador, e escolha uma estação de radio. Observe quanto tempo demora para que a música comece a tocar, a qualidade do som, e sua continuidade.

Como é feito o acesso às estações de rádio, e como as músicas são transportadas pela rede ?

  • Execute o wireshark e repita o acesso à estação. Enquanto a captura acontece, observe os protocolos envolvidos e as mensagens que fluem entre seu computador e o servidor da estação. Observe também onde a estação se localiza (país/cidade).
  • Você conseguiria descrever como funcionam seus acessos e transmissões ?

09/10: Caracterização de midias

Compressão de video

Técnicas usadas para compressão de video:

  • Remoção de redundância espacial - codificação intraquadros (ex: JPEG)
  • Remoção de redundância espacial e temporal - codificação intraquadros e interquadros (H.261, MPEG)


Remoção de redundância temporal: iniciando com um intraquadro (quadro I), quadros sucessivos contém atualizações relativas a quadros anteriores (quadros P) ou a quadros anteriores e posteriores (quadros B). O conjunto de quadros entre quadros I se chama GOP (Group of Pictures):


Gop.png


Exemplos de codecs de video

  • MPEG-2
  • H-264
  • XVID
  • Theora

Exemplos de formatos de video usados em MPEG2 (i.e. em DVD): Mpeg2-video-formats.png

Atividade

1) Copie este video para seu computador. Visualize-o com mplayer ou vlc, observando sua qualidade de imagem. Veja também o tamanho desse arquivo de video, que está codificado com MJPG.

2) Codifique esse video para outros formatos de compressão:

  • MPEG-2: mencoder -o sr-mpeg2.mpg -of mpeg -ovc lavc -lavcopts vcodec=mpeg2video:vbitrate=250 -oac copy sr.mjpg
  • XVID: mencoder -o sr-xvid.avi -ovc xvid -xvidencopts bitrate=250 -oac copy sr.mjpg
  • H-264:
    mencoder -o sr-h264.mp4 -ovc x264 -x264encopts pass=1:turbo -oac mp3lame sr.mjpg
    mencoder -o sr-h264.mp4 -ovc x264 -x264encopts bitrate=250:pass=2 -oac mp3lame sr.mjpg
  • Theora:
    mencoder -o sr-theora.mp4 -of mpeg -ovc lavc -lavcopts vcodec=libtheora:vpass=1:turbo -oac mp3lame sr.mjpg
    mencoder -o sr-theora.mp4 -of mpeg -ovc lavc -lavcopts vcodec=libtheora:vpass=2 -oac mp3lame sr.mjpg

3) Compare os tamanhos dos arquivos de video resultantes das codificações. Toque-os e veja se há diferença de qualidade de imagem entre eles.

4) Um software de processamento de video disponível para Linux se chama gopchop. Abaixo segue um texto explicativo sobre esse programa:

Gopchop.png

Interprete as informações contidas no texto acima, e experimente usar o gopchop.

TAREFA: mecanismos de distribuição de midia

Faça uma breve descrição de um mecanismo de distribuição de midia, que pode estar armazenada ou ser ao vivo. Explique como os dados são codificados, que protocolos são usados e que mensagens são trocadas para que o acesso a midia se realize. Inclua diagramas para ajudar a explicar seu funcionamento, e forneça exemplos de sua aplicação.

Algumas sugestões de mecanismos:

  • HTTP Live streaming
  • HTTP Pseudo-streaming
  • HTTP Dynamic-streaming
  • RTSP streaming
  • P2P streaming
  • ... outros ?

IMPORTANTE: Na próxima aula (16/10) sortearei dois alunos para que apresentem seus trabalhos. Se fizerem uma boa apresentação ficarão com crédito (que poderá melhorar seu conceito final). Se não apresentarem ou não trouxerem um bom material, ficarão com um ponto negativo (i.e. conceito final pode ser arredondado pra baixo).

Sobre distribuição P2P

11/10: Caracterização de midias

Compressão de audio

Técnicas usadas:

  • Remoção de silêncio
  • Uso de psicoacústica
  • Remoção de redundância

Exemplo de codificação:

Audio-codec.png

Atividade

1) Copie este arquivo de audio para seu computador. Escute-o e confira sua qualidade sonora. Veja também o tamanho do arquivo.

2) Codifique esse arquivo com os seguintes codecs:

  • MP3: time lame musica.wav musica.mp3
  • Ogg: time oggenc -o musica.ogg musica.wav
  • Flac: time flac musica.wav -o musica.flac
  • Speex: time speexenc --bitrate 8 musica.wav musica.spx

3) Toque os arquivos de audio codificados, comparando suas qualidades sonoras. Compare também os tamanhos dos arquivos.

Transmissão de dados multimidia


  • Atrasos devido a transmissão

Rt-traffic.png


  • O tráfego de midia pode variar o uso de banda dependendo da codificação:

Rt-transmission.png

Estratégias para tratar a variação de atraso

Mecanismos para compensar atraso e variação de atraso da rede:

  • Numerar cada mensagem com um número de sequência.
  • Registrar o instante em que cada mensagem foi gerada (i.e. registrar seu timestamp).
  • Atrasar a reprodução do conteúdo no receptor, para compensar variações de atraso.


Esses mecanismos são combinados nas seguintes estratégias para compensar variação de atraso:


Atraso de reprodução fixo

Compensa atrasos de mensagens com a imposição de um atraso fixo q no reprodutor de midia. Mensagens recebidas após seu instante de reprodução (i.e. chegam após timestamp + q) são descartados.


Atraso-de-reproducao-fixo.png
Atraso de reprodução: midia será tocada somente no instante , sendo que . O atraso q corresponde ao atraso de reprodução imposto do lado do cliente, para compensar variações de atraso das mensagens.


Por exemplo, uma sequência de mensagens pode ser reproduzida da seguinte forma se for imposto um atraso fixo:

Atraso-de-reproducao-fixo2.png


Atraso de reprodução adaptativo

Procura minimizar o atraso de reprodução, estimando o atraso da rede e sua variação. O atraso de reprodução assim calculado é imposto no receptor antes de cada rajada de mensagens (isso faz mais sentido em transmissão de voz).


Por exemplo, uma sequência de mensagens pode ser reproduzida da seguinte forma se for imposto um atraso adaptativo:

Atraso-de-reproducao-adaptativo-1.png


Se uma determinada mensagem se atrasar além do tolerável, será descartada (não reproduzida):

Atraso-de-reproducao-adaptativo-2.png

Exercícios

Resolver os exercícios contidos no final das transparências.

16/10: Transmissão de dados multimidia

  • Não houve aula ... fomos ver a apresentação de TCC1 no auditório.

Atividade: atraso de reprodução (extra ... fazer fora da aula)

Use este programa para simular um buffer de reprodução com atraso fixo. Para testá-lo faça o seguinte

  1. Execute-o com o comando: 
    python playbuffer.py
  2. Visualize o video transferido por esse buffer: 
    mplayer slalom2.mpg
  3. Experimente variar o atraso de reprodução, editando o programa e redefinindo a variável global Atraso. Teste colocá-la com o valor 0 para desativar o atraso de de reprodução.


Quais devem ser o atraso e variação de atraso do streaming de video que fizemos na aula de 04/10 ? Poderíamos estimar essas características de transmissão para o video que estava em um servidor dentro do IF-SC São José, e para aquele outro que estava em um computador fora da escola.

  1. Qual deveria ser o atraso de reprodução mínimo, em cada caso, para que o video pudesse ser reproduzido sem perdas ?
  2. Qual seria o valor desse atraso mínimo, se fosse calculado segundo o procedimento para determinar o atraso de reprodução adaptativo

18/10: VoIP e Asterisk


Asterisk: uma solução completa de PABX baseado em software, permitindo ligar o mundo IP ao mundo da rede pública de telefonia comutada.

Características Básicas: faz tudo que um PABX pequeno e simples faz e pouco mais

  • ˆ Transferência, música de espera, siga-me, etc.
  • Conferência, correio de voz, URA, fila de chamadas, monitoramento de chamadas, integração com o Jabber (Google talk)

Características Avançadas: o que seria interessante para grandes empresas

  • Uso de banco de dados (MySQL), integração com o LDAP, DUNDi, DNS SRV, geração de bilhetagem


Asterisk-ex1.png
Exemplo de cenário de uso do Asterisk


Plano de discagem

O plano de discagem define como cada chamada deve ser processada. As instruções de processamento residem no arquivo de configuração extensions.conf. O fluxo de processamento de chamadas pode ser visto resumidamente abaixo:

Asterisk-fluxo.png


Um exemplo de plano de discagem simples pode ser visto abaixo: 

[alunos]; o nome deste contexto

# Chamadas para o número 101 são feitas via SIP para o canal "maria"
exten=>101,1,Dial(SIP/maria)
same=>n,Hangup()

# Chamadas para "teste" serão atendidas com um som de beep, seguido 
# da reprodução do arquivo de som "hello-world", em seguida outro beep e
# enfim se encerra a chamada.
exten=>teste,1,Playback(beep)
same=>n,Wait(1)
same=>n,Playback(hello-world)
same=>n,Wait(1)
same=>n,Playback(beep)
same=>n,Hangup

A estrutura do plano de discagem é composta por extensões (um termo específico do Asterisk). Cada extensão identifica um número (ou usuário) que pode ser chamado, e como essa chamada deve ser processada. A sintaxe pode ser vista abaixo: 

exten=>identificador,prioridade,aplicação
  • identificador: o número ou usuário chamado
  • prioridade: a prioridade da extensão. Isso determina a ordem de execução das extensões que tratam do mesmo identificador.
  • aplicação: uma ação a ser realizada quando a extensão for processada. Por exemplo, a aplicação Dial determina que deve ser encaminhada a outro canal.

Como o processamento de uma chamada usualmente envolve uma sequência de extensões, existe uma sintaxe opcional para simplificar a declaração: 

exten=>identificador,prioridade,aplicação
same=>prioridade,aplicação
  • same: declara uma nova extensão com mesmo identificador da extensão imediatamente anterior

Por fim, a prioridade (que define a ordem com que as extensões são processadas) declarada com o valor n equivale à prioridade da extensão imediatamente anterior incrementada em uma unidade: 

exten=>101,1,Dial(SIP/101)
same=>n,Hangup; a prioridade aqui terá o valor 2

Canais SIP

Cada telefone SIP deve ter seu identificador cadastrado no Asterisk. O identificador pode tanto ser um número, análogo a um ramal, ou uma string alfanumérica. No terminologia do Asterisk, cada telefone SIP é chamado de canal SIP, e deve estar declarado em /etc/asterisk/sip.conf: 

; Canal 2000 (um exemplo)
[2000]
username=2000 ; o nome do usuário para fins de autenticação
secret=kabrum
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 passo),
                     ; assim como acontece em sessões Web
context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá
disallow=all
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
guida,
          ; já que cada um deles tem suas particularidades.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.

; Canal joao (outro exemplo)
[joao]
username=joao ; o nome do usuário para fins de autenticação
secret=blabla
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 passo),
                     ; assim como acontece em sessões Web
context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá
disallow=all
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
guida,
          ; já que cada um deles tem suas particularidades.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.

Como se pode notar, a declaração de um canal SIP envolve muitos parâmetros que envolvem autenticação, controle de acesso, localização na rede, codecs e possivelmente outras capacidades. Como os valores de alguns parâmetros podem ser iguais para vários canais, o Asterisk possibilita a declaração de perfis (templates): 

; Perfil alunos
[alunos](!);  a sequência "(!)" define isto como um perfil
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 passo),
                     ; assim como acontece em sessões Web
context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá
disallow=all
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
guida,
          ; já que cada um deles tem suas particularidades.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.

; Canal 2000
[2000](alunos); a sequência "(alunos)" copia as definições do perfil "alunos"
username=2000 ; o nome do usuário para fins de autenticação
secret=kabrum

; Canal joao
[joao](alunos)
username=joao ; o nome do usuário para fins de autenticação
secret=blabla

Atividade

Para realizar esses exercícios você deve primeiro instalar o Asterisk na máquina virtual rmu-server. Para testar as chamadas, use o softphone jitsy na máquina real.


  1. Criar as seguintes contas SIP e contextos:
    • alunos: Contas 100 e 101
    • professores: Contas 200 e 201
    • coordenacao: Contas 300 e 301
sip.conf 
[general]
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 passo),
                     ; assim como acontece em sessões Web
disallow=all
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
guida,
          ; já que cada um deles tem suas particularidades.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.

[alunos](!)
context=alunos

[professores](!)
context=professores

[coordenacao](!)
context=coordenacao
 
[100](alunos)
username=100
secret=100

[101](alunos)
username=101
secret=101

[200](professores)
username=200
secret=200

[201](professores)
username=201
secret=201

[300](coordenacao)
username=300
secret=300

[301](coordenacao)
username=301
secret=301


extensions.conf 
[alunos]; contexto alunos
; extensoes dos alunos

[professores]; contexto professores
; extensoes dos professores

[coordenacao]; contexto coordenacao
; extensoes da coordenacao
  1. Criar um plano de discagem de forma que as contas SIP do contexto alunos só possam atingir outras contas SIP deste contexto. Faça o mesmo para o contexto professores.ˆ Contas SIP do contexto coordenação poderão atingir, além das contas SIP desse contexto, as contas dos contextos alunos e professores.
  2. Execute duas instâncias do Jitsy, sendo que uma delas deve ser configurada para usar a porta 5060, e a outra deve usar a porta 5061. Essas portas servirão para efetuar trocas de mensagens SIP, que é o protocolo usado para iniciar e terminar as chamadas VoIP.
  3. Adicione uma conta a cada softphone. Use as contas criadas no ítem 1.
  4. A partir de um softphone faça uma chamada para a conta do outro softphone. Verifique se o softphone destino acusou o recebimento de chamada. Caso isso não tenha ocorrido, verifique seu plano de discagem.
  5. Execute o wireshark, e ponha-o em modo de captura em todas as interfaces (pseudo-interface any).
  6. Repita a chamada de um softphone a outro. No softphone destino atenda a chamada, e alguns segundos depois encerre-a.
  7. No wireshark interrompa a captura, e em seguida acesse o menu Telephony->VoIP Calls. Selecione uma chamada, e visualize o diagrama de mensagens SIP. Siga cada mensagem SIP (clique no diagrama), e observe a mensagem selecionada no painel de captura do wireshark.

TAREFA: Leitura da Semana

O texto desta semana diz respeito à sinalização SIP, usada em VoIP. Leiam até a página 10 deste artigo, e preparem-se para discuti-lo (e apresentá-lo) nesta 3a feira, 23/10.


23/10: A sinalização SIP e Protocolos de Tempo-Real

  • RTP (Real Time Protocol): Protocolo de transporte para conteúdo de tempo-real
    • Identificação do tipo do conteúdo que está sendo carregado (codec)
    • Numeração de sequência
    • Marcação de tempo (timestamp) para possibilitar sincronização com a fonte e cálculo de variação de atraso
    • Monitoramento da entrega (recepção da stream)
    • Não provê garantias de QoS !
  • RTCP (Real Time Control Protocol): Protocolo auxiliar ao RTP, para fornecer um feedback dos clientes quanto a streaming.
    • Retorno sobre o desempenho da aplicação e da rede
    • Informações para sincronização de fluxos de video e áudio
Rtp1.png
Localização do RTP na camada de transporte		 Rtp-header.png
Cabeçalho RTP


Atividade

Essa atividade busca ilustrar os fluxos RTP com um exemplo:

  1. Acesse o servidor de streaming de video RTSP usando o aplicativo vlc: 
    vlc rtsp://172.18.200.251/rmu.sdp
  2. Execute o wireshark e ative a captura de datagramas UDP.
  3. Observe os pacotes RTP capturados pelo Wireshark. Selecione alguns deles e investigue as informações contidas em seu cabeçalho. Procure identificar o codec usado e as marcações de tempo. Compare as marcações de tempo do RTP com os instantes de recepção desses pacotes.
  4. Estime o jitter durante a recepção de ao menos 15 segundos de video.

25/10: A sinalização SIP

Atividade 1: Ligação SIP ponto a ponto

  1. Capturar pacotes com wireshark e analisar mensagens SIP (menu Telephony -> Voip Calls -> Graph)
  2. Ouvir a conversa capturada (é necessário usar o CODEC G711)


Questões:

  1. Qual o CODEC selecionado por cada parte?
  2. Qual a lista de CODECS?
  3. Existem mensagens RTCP? Qual a porta?
  4. Existe algum registro SIP?
  5. Existe a entidade SIP proxy nesse cenário?
  6. Existe a entidade RTP proxy nesse cenário?


Atividade 2: Ligações SIP tendo um PABX Asterisk

  1. Necessário instalar Asterisk na VM do professor e criar contas SIP para cada aluno
  2. Capturar pacotes com wireshark e analisar

Questões:

  1. Por que a 1a. tentativa de REGISTER tem como resposta "não autorizado"?
  2. Existe a entidade SIP proxy nesse cenário?
  3. Existe a entidade RTP proxy nesse cenário?
    • O fluxo RTP é intermediado?
  4. Nesse cenário haveria algum problema se uma das partes estiver através de um NAT?

30/10: Uma infraestrutura para telefonia com PBX IP

Para continuar nosso estudo sobre telefonia IP, usaremos como base o seguinte modelo de rede:

Modelo-pbx-asterisk.png

Esse modelo precisa de alguns componentes para ser implantado:

  • PBX IP, representado pelo Asterisk
  • Telefones IP ou softphones IP como o Jitsi
  • Telefones convencionais
  • Interfaces para integrar telefones convencionais ao PBX IP
  • Interfaces para integrar o PBX IP e PSTN por meio de linha analógica ou um tronco E1

A rede de estudo pode ser dividida em uma parte em que as chamadas são efetuadas de forma convencional, e outra parte em que chamadas são feitas com VoIP usando o modelo SIP. O PBX IP consegue atender ambos os tipos de rede telefônica, assim como integrá-los. Desta forma, uma chamada originada em um telefone convencional pode ser destinada tanto a outro telefone convencional quanto a um telefone IP, e vice-versa. A integração entre as duas redes depende, além do PBX IP, de hardware específico.

Existem componentes de hardware para possibilitar que um PBX Asterisk se comunique via tronco analógico, digital ou rede celular, além de atender telefones convencionais. Tais componentes provêem os seguintes tipos de interface:

  • FXS: usada para conectar telefones convencionais (POTS), atuando como uma porta de ramal.
  • FXO: usada para comunicação por um tronco analógico (POTS), sendo conectada a uma linha fornecida pela PSTN ou por um PBX analógico (ou pela interface FXS de outro PBX).
  • E1: conectada a um tronco E1, que pode ser fornecido pela PSTN ou outro PBX.
  • GSM: usada para acesso à rede celular.

Inicialmente criaremos a infraestrutura para chamadas VoIP, a qual aumentaremos gradualmente para podermos reproduzir o modelo aqui descrito.

Tronco SIP

Em um entroncamento SIP (SIP trunking), um PBX pode encaminhar chamadas através de um tronco SIP. Essas chamadas podem ser originadas de diferentes formas, tais como telefones IP ou convencionais. Entre os PBX do entroncamento, as chamadas são sinalizadas com SIP e transmitidas com RTP e algum codec.

Sip-trunk.png

A ativação de um entroncamento SIP entre dois PBX Asterisk pode ser feita seguindo o exemplo abaixo:

PBX Norte

  • Arquivo sip.conf:
     ; Definição do UAC Sul

[Sul]
type=user
secret=supersercreta
host=IP_PBX_Norte
disallow=all
allow=ulaw
;canreinvite=no
directmedia=no
context=troncoSIP
qualify=yes

[ParaSul]
type=peer
fromuser=Norte
username=Norte
secret=supersecreta
host=IP_PBX_Sul
disallow=all
allow=ulaw
;canreinvite=no
directmedia=no
qualify=yes
  • Arquivo extensions.conf:
     ...
 [troncoSIP]
 ; Ligando para a outra central e, na sequência, o "ramal" de destino
 exten => _0.,1,Dial(SIP/ParaSul/${EXTEN:1})

PBX Sul

  • Arquivo sip.conf:
     ; Definição do UAC Norte
[Norte]
type=user
secret=supersercreta
host=IP_PBX_Sul
disallow=all
allow=ulaw
;canreinvite=no
directmedia=no
context=troncoSIP
qualify=yes

[ParaNorte]
type=peer
fromuser=Sul
username=Sul
secret=supersecreta
host=IP_PBX_Norte
disallow=all
allow=ulaw
;canreinvite=no
directmedia=yes
qualify=yes
  • Arquivo extensions.conf: 
     [troncoSIP]
 ;
 ; Ligando para a outra central e, na sequência, o "ramal" de destino
 exten => _0.,1,Dial(SIP/ParaNorte/${EXTEN:1})

Atividade: estabelecendo chamadas entre diferentes PBX Asterisk

Nesta atividade, vamos realizar chamadas entre softphones registrados em diferentes PBX Asterisk. Para isso, precisaremos estruturar o laboratório de forma que cada PBX Asterisk possua um tronco SIP com um PBX vizinho. Os usuários SIP serão identificados por MMXX, sendo MM o número do computador de cada aluno (ex: micro 2 tem usuários entre 200 e 299). Assim, é possível fazer um plano de discagem para encaminhar corretamente as chamadas.

06/11: Interligando PBX Asterisk

Nesta atividade vamos integrar os servidores Asterisk de todos os alunos no laboratório. Usaremos uma estrutura hierárquica como ilustrado abaixo:


Asterisk-hierarquia-lab2.png


Em um primeiro momento, o servidor Asterisk do professor terá o papel de encaminhar chamadas entre os servidores dos alunos. Mas para que isso seja viável e escalável, cada aluno deve usar uma numeração de ramais que possa ser univocamente identificada. Assim, cada servidor Asterisk deve numerar seus ramais da seguinte forma:

  • 21XX: números do aluno 1
  • 22XX: números do aluno 2
  • 23XX: números do aluno 3
  • 30XX: números do aluno 10
  • 34XX: números do aluno 14

A interligação entre os servidores Asterisk do professor e alunos será implantada por um tronco E1. Para isso serão usados dois módulos EBS da Khomp. Um dos PBX de alunos deve ser configurado para usar um módulo EBS, e fazer o encaminhamento e recebimento de chamadas via tronco E1. Com isso, todas as chamadas de telefones de diferentes PBX passarão pelo tronco E1 e pelo PBX do professor.

Questões para refletir

  1. O encaminhamento de chamadas nesse cenário poderia ser melhorado. As chamadas entre ramais de PBX de alunos não precisariam passar pelo tronco E1. O que seria necessário modificar para que isso fosse implantado ?
  2. E se ao invés do tronco E1 fosse usado um tronco IAX2 ou SIP ? Que vantagens ou desvantagens existiriam nesse caso ?

08/11: Prática com Asterisk: aplicações e funções típicas de PBX

Algumas funções típicas de PBX são:

  • Transferência de chamadas
  • Captura de chamadas
  • Estacionamento de chamadas
  • Gravação de chamadas
  • Música em espera
  • Sala de conferência
  • Correio de voz
  • Siga-me (se ocupado, imediato ou se não atender)
  • Lista negra
  • Não perturbe
  • Rediscagem

Essas funcionalidades podem ser implementadas no próprio PBX ou no telefone. No caso do Asterisk, elas podem ser disponibilizadas diretamente pelo próprio Asterisk, ou ser implementadas no plano de discagem. A figura abaixo ilustra essas possibilidades:

Recursos-pbx.png
Funções disponíveis em um PBX Asterisk - figura obtida de: Flávio Gonçalves. Guia de Configuração para Asterisk PBX, 5a edição.

Para criar essas funções em um PBX Asterisk, é necessário conhecer os recursos que ele oferece. Dentre esses recursos, há aplicações, variáveis, e características (features). Hoje serão vistos alguns deses recursos, que usaremos para implantar algumas das funções enumeradas acima.

Extensões especiais

Além das extensões criadas pelo usuário, o Asterisk apresenta algumas extensões especiais, tais como:

  • s (start): tem por objetivo tratar qualquer chamada que entre em um contexto e que não tenha um destino específico.
  • i (invalid): tem por objetivo tratar entradas inv ́lidas em um menu interativo
  • t (timeout): Em um menu interativo intercepta a chamada caso o usuário não forneça uma entrada dentro de um período de tempo estipulado.

Aplicações

As aplicações são usadas no plano de discagem. Assim, o processamento de uma chamada se faz pela execução sucessiva de aplicações, de forma a se obter o efeito desejado.

NoOp

Não faz nada, sendo útil para depurar o plano de discagem. Exemplo: 

exten=>100,1,NoOp(${CONTEXT})

GoTo

Pula para um contexto (opcional), extensão, prioridade específica. Exemplo: 

exten=>100,1,GoTo(vendas,s,1)

GoToIf

Trata-se do comando GoTo condicional. Sua sintaxe é: 

GoToIf(condição?[rótulo se verdade]:[rótulo se falso])

Os rótulos podem assumir a forma: 

 [[contexto],extensão,]prioridade

Exemplo: 

[alunos]

exten=>6111,1,GoToIf($["${CALLERID(num)}" != "6112"]?2:4)
same=> n,Dial(SIP/6111,30)
same=> n,Hangup
same=> n,Answer
same=> n,Playback(hello-world)
same=> n,Hangup

Background

Toca um arquivo de som como música de fundo. Esse arquivo deve estar em /usr/share/asterisk/sounds, e ser codificado com codec PCM ou WAV.

Exemplo: 

exten=>666,1,Answer
same=>n,Background(hello-world)
same=>n,Hangup

Playback

Toca um arquivo de som. A diferença em relação a Background é que Playback devolve o controle ao Asterisk (i.e. ao plano de discagem) somente após tocar todo o arquivo. Esse arquivo deve estar em /usr/share/asterisk/sounds, e ser codificado com codec PCM ou WAV.

Exemplo: 

exten=>666,1,Answer
same=>n,Playback(hello-world)
same=>n,Hangup

Wait

Força uma espera durante o processamento da chamada.

Exemplo: 

exten=>666,1,Answer
same=>n,Playback(hello-world)
same=>n,Wait(1)
same=>n,Playback(beep)
same=>n,Hangup

Answer e Hangup

Answer atende uma chamada. Hangup termina uma chamada.

Exemplo: 

exten=>666,1,Answer
same=>n,Playback(hello-world)
same=>n,Hangup

Set

Modifica o valor de uma variável.

Exemplo: 

exten=>666,1,Set(Tentativas=1)
same=>2,Dial(SIP/666,10)
same=>3,Set(Tentativas=${Tentativas}+1)
same=>4,GoToIf($[${Tentativas} < 2]?2:5)
same=>5,Hangup

Log

Grava um texto qualquer no log do Asterisk.

Exemplo: 

exten=>666,1,Log(DEBUG,"Chamada para 666")
same=>n,Dial(SIP/666,10)
same=>n,Hangup

Variáveis

O uso de variáveis no Asterisk possui funcionamento semelhante àquele encontrado nas linguagens de programação, permitindo ao “programador” utilizar variáveis já definidas pelo Asterisk bem como definir suas próprias variáveis. As definições das variáveis devem ser feitas no arquivo extensions.conf.

A sintaxe para trabalhar com variáveis no Asterisk é semelhante a do c-shell, porém as variáveis definidas pelo usuário não são sensíveis a caixa, ou seja, VAR e var referem-se à mesma variável.

  • Para definir uma variável: VAR=valor
  • Para obter o valor de uma variável: ${VAR}

Existem três tipos de variáveis:

  • Variáveis globais: Variáveis que estarão disponíveis a todos os canais e contextos em um plano de discagem. Essas devem ser declaradas dentro do contexto [globals] existente no arquivo extensions.conf ou utilizando a função GLOBAL() no plano de discagem.
  • Variáveis do canal: Variáveis que estão associadas especificamente com uma unica ligação. São definidas durante a chamada e só estão disponíveis para os participantes desta chamada. O Asterisk já define algumas variáveis específicas ao canal (Ex: ${CALLERID(num)}).
  • Variáveis de ambiente: São as variáveis obtidas do sistema operacional. Estas são referenciadas através do comando ENV. Ex: ${ENV(path)}.

Abaixo se pode ver um exemplo de plano de discagem que usa variáveis: 

[globals]
; definicao de uma variavel global
VENDAS=SIP/6112

[alunos]
; definicao de uma variavel global atraves do comando Global e aplicacao Set
exten=> 6666,1,Set(GLOBAL(COMPRAS)=SIP/6113)
exten=> 6666,2,NoOp(${GLOBAL(COMPRAS)})

; definicao de uma variavel especifica ao canal
exten=> 7777,1,Set(teste=1)
exten=> 7777,n,NoOp(${teste})
exten=> 7777,n,Set(teste=$[${teste} + 1])
exten=> 7777,n,NoOp(${teste})
exten=> 7777,n,Hangup

Funções implementadas no próprio Asterisk

Música de espera

O Asterisk permite o uso de MP3 como música de espera, porém MP3 são arquivos complicados de se trabalhar pois requerem o uso de aplicações externas para que possam ser reproduzidos, como por exemplo mpg123. Seu funcionamento também pode não agradar muito já que em alguns casos a música pode ser reproduzida em alta rotação além de elevar a carga de processamento da máquina no caso de soluções de grande porte.

A partir da versão 1.2 do Asterisk se sugere não mais usar o mpg123. O melhor é converter arquivos MP3 para um formato que o Asterisk trate nativamente, como por exemplo, wav ou pcm (μLaw). A ferramenta ffmpeg pode ser usada para converter arquivos MP3 para WAV ou PCM. 

# convertendo o arquivo musica.mp3 para musica.wav e musica.pcm
ffmpeg -i musica.mp3 -ar 8000 -ac 1 -ab 64 musica.wav -ar 8000 -ac 1 -ab 64 -f mulaw
musica.pcm -map 0:0 -map 0:0

Os arquivos de música devem ficar em um diretório especificado para cada contexto, conforme definido no arquivo musiconhold.conf: 

# configuracao no arquivo musiconhold.conf
[alunos]
mode=files
directory=/var/lib/asterisk/moh
sort=random
# deve-se colocar os arquivos wav e/ou pcm no diretorio especificado acima

Para testar a música em espera no plano de discagem, pode-se usar a aplicação MusicOnHold: 

exten=>667,1,Set(CHANNEL(musicclass)=alunos)
same=>n,Answer
same=>n,MusicOnHold()
same=>n,Dial(SIP/667)
same=>n,Hangup

Filas de atendimento

Amplamente utilizadas nos sistemas de 0800. A configuração é feita no arquivo queues.conf: 

[fila-suporte]
musicclass=default
strategy=ringall; roundrobin, rrmemory
timeout=10
wrapuptime=30
periodic-announce = em-breve
periodic-announce-frequency=60
member=>SIP/6111
member=>SIP/6112

No plano de discagem a fila de atendimento pode ser usada da seguinte forma: 

[suporte]
exten=> s,1,Set(CHANNEL(musicclass)=suporte)
exten=> s,2,Playback(bem-vindo)
exten=> s,3,Queue(fila-suporte)

Captura de chamadas

A captura possibilita que se puxe uma chamada de um colega no mesmo grupo de chamadas. Isso evita que se tenha que levantar para atender um telefone do seu vizinho que não para de tocar. A captura pode ser feita discando *8 (isso pode ser alterado no arquivo features.conf).


Call-capture.png
Captura de chamadas - figura obtida de: Flávio Gonçalves. Guia de Configuração para Asterisk PBX, 5a edição.

Para habilitar a captura de chamadas é suficiente definir a que grupo de chamadas cada canal pertence (parâmetro callgroup), e de que grupos se pode capturar chamadas (parâmetro pickupgroup). No caso de canais SIP isso fica em sip.conf: 

[joaozinho]
callgroup=1
pickupgroup=1,2
...

Estacionamento de chamadas

O estacionamento de chamadas é feito no arquivo features.conf fazendo uso dos seguintes parâmetros:

  • parktext: Extensão utilizada para fazer o estacionamento de chamadas, após invocá-la o sistema irá indicar em qual posição a chamada atual foi estacionada.
  • ˆ parkpos: Define o número de vagas para o estacionamento de chamadas.
  • context: Define o nome do contexto para o estacionamento de chamadas. É necessário incluir este contexto nos demais contextos que poderão usar o estacionamento de chamadas.
  • parkingtime: Se definida, indica o tempo máximo que uma chamada poderá ficar estacionada. Se este tempo estourar o sistema irá fazer uma ligação para o ramal que estacionou a chamada em questão.


Parking-calls.png
Estacionamento de chamadas - figura obtida de: Flávio Gonçalves. Guia de Configuração para Asterisk PBX, 5a edição.

Abaixo se pode ver um exemplo de plano de discagem que usa estacionamento de chamadas: 

[vendas]

include=>parkedcalls

exten=>6200,1,Dial(SIP/6200,30,tT)
exten=>6200,n,Hangup

Atividade

Nesta aula faremos experimentos usando ATA, Telefone IP e softphones junto com o Asterisk. Em seguida, testaremos algumas das funções de PBX apresentadas hoje.

  1. Instale um ATA ou telefone IP, fazendo com que se registre via SIP em seu Asterisk. Teste-o realizando chamadas para um softphone, e vice-versa.
  2. Crie uma fila de atendimento com dois membros e música de espera.
  3. Crie um serviço de estacionamento de chamadas. Para testá-lo serão necessários ao menos três telefones (os dois que estabelecem originalmente a chamada, e um terceiro para capturar uma chamada estacionada).

13/11: Asterisk: URA, STUN e integração com DNS

URA

O que é uma URA (Unidade de Resposta Audível) ? Clique na imagem abaixo ...

Ura-tabajara.png
URA Tabajara

Uma URA implementa um menu audível para auto-atendimento. Sua construção é feita toda no plano de discagem, como se pode ver no exemplo abaixo: 

[default]
exten => 666,1,Goto(ura,s,1) 

[ura]
exten => s,1,Answer
exten => s,2,NoOp(Ligação entrou na URA)
exten => s,n,Background(/var/lib/asterisk/sounds/benvindo)
exten => s,n,NoOp(Digite a opção/1-suporte/2-comercial/3-financeiro)
exten => s,n,WaitExten(6); caso nada tenha sido digitado durante a mensagem "benvindo", espera mais 6 segundos no máximo

exten => 1,1,NoOp(Chamada foi para Suporte)
same => n,Dial(SIP/2402,60)
same => n, Hangup

exten => 2,1,NoOp(Chamada foi para Comercial)
same => n,Dial(SIP/2801,60)
same => n, Hangup

exten => 3,1,NoOp(Chamada foi para Financeiro)
same => n,Dial(SIP/2000,60)
same => n, Hangup

exten => i,1,NoOp(Extensão inválida)
same => n,Play(beep)
same => n,GoTo(s,3); volta para o menu

exten => t,1,NoOp(Tempo esgotado)
same => n,Dial(SIP/3401,60)
same => n,Hangup

A URA é composta por mensagens de voz, que instruem o usuário sobre o que ele pode fazer (isto é, apresentam as opções), e músicas, que o entreteem (!?) enquanto aguarda uma operação ser realizada. Assim, para criar uma URA minimamente funcional são necessários esses arquivos de voz. Para gravá-los, pode-se criar uma extensão especial que atenda por 9005nome_de_um_arquivo. Ao chamar essa estensão, pode-se pronunciar a mensagem de voz assim que o Asterisk atender. Para encerrar a mensagem, deve-se digitar #. O arquivo de voz resultante estará no diretório /var/lib/asterisk/sounds, ou em qualquer outro diretório especificado na aplicação record. 

exten=_9005.,1,answer()
exten=_9005.,n,record(/var/lib/asterisk/sounds/${EXTEN:4}.wav,5,t)
exten=_9005.,n,playback(/var/lib/asterisk/sounds/${EXTEN:4})
exten=_9005.,n,hangup()

Atividade

  1. Crie a URA Tabajara, conforme o vídeo visto na aula.
  2. Crie uma URA que possibilite um usuário SIP mudar sua senha. Dica: veja as aplicações Read e System e a função SHELL.

Implantação de uma infraestrutura VoIP

A implantação de uma infraestrutura VoIP, com telefones IP ou softphones que possam se comunicar através da Internet, deve atentar para alguns detalhes:

  • NAT: tornou-se prática usual implantar redes usando blocos de endereços privativos e um gateway NAT para interligá-la com a Internet. Isso impõe uma dificuldade para conversações VoIP que seguem o modelo SIP.
  • Localização: a realização de uma chamada entre dois usuários VoIP é trivial se ambos estiverem registrados no mesmo servidor de registro SIP (ex: no mesmo servidor Asterisk), ou se o PBX IP possuir regras em seu plano de discagem para encontrar o usuário chamado. Mas algo mais é necessário se os usuários estiverem registrados em diferentes servidores de registro, e não houver regras de plano de discagem para localizá-los. Isso guarda semelhanças com correio eletrônico.

Hoje faremos uma discussão sobre algumas técnicas que podem ajudar a resolver esses problemas.

STUN: Session Traversal Utilities for NAT


Ou: um quebra-galho para resolver os problemas de outro quebra-galho ...


O estabelecimento de uma chamada VoIP implica iniciar e manter duas streams de áudio (uma em cada sentido da comunicação). Cada stream usa o protocolo RTP, cujas PDUs são transportadas dentro de datagramas UDP. Portanto, cada telefone IP precisa alocar um port UDP, por onde serão recebidas as PDUs RTP.

Voip-call.png
Diagrama que mostra uma chamada VoIP típica intermediada por um PBX. A sinalização se faz através do PBX, mas as streams de áudio RTP são estabelecidas diretamente entre os telefones VoIP.


As informações necessárias para transmitir as PDUs da stream RTP são informadas no momento em que se inicia a chamada. Um dos telefones IP usa o protocolo SIP para solicitar uma chamada com outro telefone (mensagem INVITE). Dentro dessa mensagem INVITE é encapsulada uma mensagem SDP, que contém as informações necessárias para criar uma stream de áudio, tais como codecs aceitos, e endereço IP e port UDP onde o telefone iniciador da chamada espera receber as PDUs RTP. Se o telefone chamado aceitar a chamada, sua resposta SIP terá status 200 OK, e encapsulará uma mensagem SDP contendo a identificação dos codecs que aceita utilizar, além de seu endereço IP e port UDP onde espera receber as PDUs RTP. Assim, com base nas informações contidas nas mensagens SDP, os telefones IP podem estabelecer as streams de áudio em ambas direções. A figura abaixo ilustra uma mensagem SDP encapsulada em uma mensagem SIP INVITE.


Sdp.png
O endereço IP e o port UDP para estabelecer a stream RTP são informados dentro da mensagem SDP, quando o telefone VoIP tenta iniciar uma chamada com SIP (mensagem INVITE). A lista de codecs da mensagem SDP foi omitida por simplicidade.


Mas como essas streams de áudio podem ser estabelecidas se existir um ou mais gateways NAT entre os telefones VoIP ? A mensagem SDP com a descrição dos dados de uma stream é preenchida usando o endereço IP e port UDP do telefone VoIP. No entanto, a existência de um gateway NAT faz com que o endereço IP e port UDP desse telefone VoIP sejam diferentes para quem estiver fora de sua rede. O correto seria ter na mensagem SDP o endereço IP e port UDP que serão usados após passar o NAT - quer dizer, os valores que serão visíveis para o outro telefone VoIP. Para isso foi criado o serviço STUN (Session Traversal Utilities for NAT), que possibilita que um telefone VoIP (ou qualquer outro cliente) descubra seu endereço IP e port UDP visíveis para quem estiver do outro lado do gateway NAT. A figura abaixo ilustra como o STUN poderia ser usado para essa finalidade.

STUN.png
Cenário em que se poderia usar STUN


O STUN foi criado para ser usado imediatamente antes de iniciar uma transmissão UDP. Como mostrado na figura abaixo, um cliente envia a um servidor STUN uma mensagem de pedido de vinculação (binding request), que deve usar como port UDP de origem o mesmo port que se pretende usar para a stream de áudio. Esse servidor STUN deve estar fora da rede, de forma que o pedido de vinculação por ele recebido seja modificado pelo NAT. A resposta do servidor STUN (binding response) contém o endereço IP e número de port UDP que apareceram no pedido de vinculação. Com isso o cliente consegue descobrir como esses valores deverão aparecer após passarem pelo NAT. Assim, a mensagem SDP pode ser preenchida com os valores apropriados para a stream de áudio.


Stun-diagram.png
Exemplo de mensagens trocadas com STUN


Deve-se notar que o STUN não faz milagre ! Como apontado no início do texto, STUN é um quebra-galho criado para tentar resolver os problemas de outro quebra-galho (no caso, o NAT). Para que o STUN funcione, o NAT deve permitir que datagramas UDP vindos de outro endereço IP (o telefone VoIP na outra ponta da ligação) acessem o endereço IP e port UDP que foram alocados quando da consulta do cliente para o servidor STUN. Como será visto em uma aula futura, isso só é possível se o NAT for do tipo full cone, restricted cone ou port restricted cone. Quer dizer, se o NAT for do tipo simétrico, o STUN não funcionará. E muitos NAT em equipamentos proprietários são do tipo simétrico (ao contrário do Linux, que implementa um NAT port restricted cone) ...

NAT e Asterisk

O Asterisk pode ajudar a viabilizar a comunicação com telefones VoIP que estão atrás de gateways NAT. Na definição de cada canal SIP devem-se incluir as opções: 

nat=yes
qualify=yes
directmedia=no

Aqui tem uma boa explicação sobre o que fazem essas opções.

Se for o Asterisk que está atrás de NAT, então deve-se configurar seu IP válido, de forma que o PBX possa informá-lo nas mensagens SDP para as streams de audio. Para isso, deve-se acrescentar em sip.conf: 

[general]
externip=IP_público
; ou:
;externhost=fqdn

; devem-se informar as redes privativas onde está o Asterisk (pode haver mais de uma ... basta repetir o 
; atributo localnet para cada subrede). Isso é importante para que o Asterisk saiba quando usar o IP
; público (para telefones fora de sua rede) ou privativo (telefones dentro de sua rede) nas mensagens
; SDP que especificam o IP e port UDP para as streams RTP.
localnet=prefixo/máscara


OBS: isso só funciona quando o Asterisk está no caminho da stream de áudio. No caso de telefones VoIP que conversam diretamente, só resta STUN ou alguma outra técnica do tipo ...

Servidores STUN

Existe uma implementação de um servidor STUN para Linux (disponível no Ubuntu via apt). Basta instalá-lo em um computador e usá-lo como servidor STUN, contanto que ele esteja do outro lado do NAT. No entanto, existem inúmeros servidores STUN públicos, conforme mostrado na listagem abaixo: 

provserver.televolution.net
sip1.lakedestiny.cordiaip.com
stun1.voiceeclipse.net
stun01.sipphone.com
stun.callwithus.com
stun.counterpath.net
stun.endigovoip.com
stun.ekiga.net (alias for stun01.sipphone.com)
stun.ideasip.com (no XOR_MAPPED_ADDRESS support)
stun.internetcalls.com
stun.ipns.com
stun.noc.ams-ix.net
stun.phonepower.com
stun.phoneserve.com
stun.rnktel.com
stun.softjoys.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
stunserver.org see their usage policy
stun.sipgate.net
stun.sipgate.net:10000
stun.voip.aebc.com
stun.voipbuster.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
stun.voxalot.com
stun.voxgratia.org (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
stun.xten.com
numb.viagenie.ca (http://numb.viagenie.ca) (XOR_MAPPED_ADDRESS only with rfc3489bis magic number in transaction ID)
stun.ipshka.com inside UA-IX zone russsian explanation at http://www.ipshka.com/main/help/hlp_stun.php

Maiores detalhes sobre servidores STUN

Integração com DNS

Uma rede representada por um determinado domínio DNS pode ter seu próprio servidor SIP. Seria conveniente que o endereço desse servidor pudesse ser obtido com uma mera consulta DNS. Isso se assemelha ao caso do correio eletrônico, em que o endereço do MTA de um domínio pode ser descoberto consultando-se seu registro MX. De fato, existe uma forma de descobrir o servidor SIP associado a um domínio DNS. Para isso, deve-se explorar o uso de registros DNS do tipo SRV.

Um registro SRV, cuja definição se encontra na RFC 2782, possibilita descobrir o nome DNS e o port (TCP ou UDP) de um servidor que responde por um determinado serviço. No caso do SIP de um domínio, o registro SRV deve ser especificado da seguinte forma: 

_sip._udp SRV 0 5060 nome.do.servidor.sip.

... sendo 0 a prioridade desse servidor (positivo, e quanto menor, maior a prioridade), 5060 o port onde ele atende requisições, e nome.do.servidor.sip seu nome DNS.

O próprio serviço STUN pode ser obtido usando registros SRV, mas isso depende do telefone VoIP (ou do PBX, caso ele esteja fazendo papel de participante em uma chamada VoIP). Nesse caso, o registro SRV deve ser definido da seguinte forma: 

_stun._udp SRV 0 3478 nome.do.servidor.stun.

Atividade

Hoje vamos continuar a atividade da semana passada, em que se criou uma infraestrutura com múltiplos PBX Asterisk. Vamos incrementá-la implantando as seguintes melhorias:

  1. Execute uma máquina virtual Ubuntu Desktop, mas antes configure sua interface ethernet para operar em modo NAT.
  2. Instale o softphone Jitsi nessa máquina virtual. Configure-o para usar o seu PBX.
  3. Execute o wireshark, e deixe-o capturando datagramas UDP em todas as interfaces de rede.
  4. Tente realizar uma chamada entre softphone e telefone IP. A chamada foi realizada ? O que mostrou o wireshark ?
  5. Configure o softphone e o telefone IP para usarem o servidor STUN instalado em 192.168.2.1.
  6. Tente novamente realizar uma chamada entre softphone e telefone IP. A chamada foi realizada ? O que mostrou o wireshark ?


TAREFA: Leitura da semana

Usando este ponto de partida prepare uma apresentação sobre VoIP federada. Você pode se referir também ao serviço fone@RNP para ajudar na explicação.

20/11: Trabalho Asterisk

Uma empresa possui uma matriz e filiais em outras cidades, cuja rede telefônica atual se baseia em links E1 e troncos analógicos entre os PBX. Uma reestruturação pretende substituir esses links por troncos SIP ou IAX2, a serem estabelecidos através dos links de dados. A nova estrutura será baseada em PBX Asterisk, da qual os links telefônicos convencionais serão removidos.


O modelo da rede telefônica em cada unidade da empresa deve se compor de:

  • PBX IP Asterisk
  • telefones IP, softphones e telefones convencionais
  • ao menos um tronco analógico para a PSTN
  • um link para Internet


Nessa nova rede, as chamadas devem ser realizadas da seguinte maneira:

  • chamadas para números de outras unidades da empresa devem ser encaminhadas diretamente ao PBX correspondente
  • chamadas para PSTN devem ser encaminhadas preferencialmente para o PBX mais próximo do número chamado (isso depende do código de área)
    • uma chamada para PSTN deve ser precedida pelo dígito 0 (zero).
    • caso isso falhe (ex: linha da filial já esteja em uso), a chamada deve ser feita diretamente pela linha telefônica local.

A Matriz será implantada pelo professor, e cada equipe implantará uma filial.

Implante essa estrutura, assumindo que os troncos IAX2 entre PBX das unidades da empresa devam ser autenticado com usuário EquipeXX e senha SenhaXX (a matriz tem usuário Matriz e senha Matriz). Além disso, a estrutura deve atender a estes requisitos:

  1. Os troncos entre PBX das unidades da empresa devem ser IAX2.
  2. Ramais da empresa possuem quatro dígitos, sendo que o primeiro dígito representa a unidade da empresa (8: Matriz, 1 a 7: filiais). O ramal 9 chama a telefonista, e o prefixo 0 direciona a chamada para a PSTN.
  3. A telefonista fica na matriz.
  4. Os ramais em cada unidade da empresa são divididos em: administração e produção. Ramais da produção podem fazer captura de chamadas somente entre si, mas os da administração podem fazer captura de todos os ramais.
  5. O ramal especial 6XXX dá acesso ao SAC da empresa, que está replicado em cada unidade da empresa. Esse é feito inicialmente por uma URA, que deve oferecer um menu com as seguintes opções:
    1. Dúvidas sobre produtos, que são encaminhadas ao setor de vendas.
    2. Clientes corporativos, que são encaminhadas ao setor de marketing.
    3. Outras necessidades, que são encaminhadas à telefonista.

Orientações:

  • O trabalho pode ser feito por equipes de no máximo três alunos.
  • A entrega do trabalho deve ser feita até o dia 27/11.
  • O trabalho deve ser demonstrado dentro do laboratório de Redes 2, estando os membros da equipe sujeitos a questionamentos.
  • Deve ser entregue um relatório contendo uma explicação sobre como foram implementadas as características e funcionalidades da estrutura, incluindo as configurações que foram realizadas no Asterisk.

Tabela de equipes

Equipe Membros Ramais IP Código de área
1 Kalvim, Ana 1000 a 1999 192.168.2.201 41
2 Mário,Maicky 2000 a 2999 192.168.2.202 43
3 Fabiano, Leandro, Lia 3000 a 3999 192.168.2.203 49
4 Emanuel 4000 a 4999 192.168.2.204 47
5 André, Luiz Gustavo 5000 a 5999 192.168.2.205 51
6 Marine 7000 a 7999 192.168.2.207 55
Matriz Professor 8000 a 8999 192.168.2.101 48


OBS: para ativar o endereço IP de sua equipe, execute o seguinte comando no sistema hospedeiro: 

sudo ifconfig eth0 IP_da_sua_equipe
sudo route add default gw 192.168.2.1

Como criar a rede de desenvolvimento

A rede de cada unidade da empresa tem uma estrutura como mostrado na seguinte figura:

Trab-asterisk-1.png


Para desenvolver o trabalho, essa rede deve em parte ser feita com máquinas virtuais (VM) Virtualbox. Para fins de simplificação, o PBX e o roteador podem ser implantados na mesma VM. No laboratório, a VM a ser utilizada se chama RMU-Asterisk, que já possui o Asterisk instalado e os demais softwares necessários para usar o módulo EBS Khomp. Existem diferentes formas de configurar essas VM, sendo uma delas a mostrada abaixo:


Trab-asterisk-2.png


  1. A VM deve ter uma interface de rede em modo NAT (para acesso à rede externa) e outra em modo bridge (para acessar o módulo EBS). A interface em modo bridge deve usar um endereço IP estático com valor 10.0.X.1/24, sendo X o número da equipe. O módulo EBS, ao ser configurado, deve usar um endereço IP 10.0.X.2/24.
  2. Na VM faça o seguinte:
    1. Instale os seguintes softwares com apt-get: openjdk-6-jre libxalan2-java
    2. Certifique-se de que o conteúdo do arquivo /etc/network/interfaces esteja assim: 
      auto lo eth0

iface lo inet loopback

iface eth0 inet dhcp
    3. Após reiniciar a VM, obtenha o Jitsi e instale-o assim: 
      sudo dpkg -i jitsi_1.0-latest_i386.deb

Como criar o tronco IAX2

Para criar o tronco IAX2 com os demais PBX, insira a seguinte configuração em /etc/asterisk/iax.conf: 

; XX: número da sua equipe
; YY: número da equipe do outro PBX
[EquipeXX-YY]
type=friend; pode iniciar e receber chamadas
username=EquipeYY-XX; identidade do asterisk da outra ponta do canal
context=seu_contexto; contexto em que processa chamadas recebidas
callerid="PBX EquipeXX"
secret=SenhaXX; senha para autenticar a chamada (iniciadas e recebidas)
host=IP_do_PBX_YY; endereço IP do asterisk na outra ponta do tronco
peercontext=rmu; contexto que deve processar a chamada no asterisk destino

No plano de discagem você deve encaminhar chamadas por esse canal IAX2. Por exemplo, se quiser chamar o número 33812850, a aplicação Dial no plano de discagem deve ser invocada assim: 

exten=>33812850,1,Dial(IAX2/EquipeXX-YY/033812850)

Note que esse exemplo deve ser adaptado no seu plano de discagem para que fique genérico, possibilitando chamar qualquer número da PSTN através desse canal IAX2.

22/11: Trabalho 1

E MCC 2012.

...

27/11: Introdução à qualidade de serviço (Qos)

Como medir a qualidade de serviço de uma rede ?

  • Disponibilidade ?
  • Largura de banda
  • Latência (atraso fim-a-fim)
  • Variação de atraso (jitter)
  • Perda de pacotes


Rmu-tabela-qos.png
Um comparativo de requisitos de QoS de algumas aplicações


  • Como prover QoS ?

Qos-tarefas.png


Uma pequena experiência

Nessa experiência, todos vão realizar um download simultâneo de um grande arquivo. Enquanto isso, um dos alunos vai visualizar um video via streaming.

  1. Para fazer o download: 
    wget http://tele.sj.ifsc.edu.br/~msobral/ubuntu.iso
  2. Para ver o video: execute vlc http://172.18.200.251/~msobral/video.avi
  • Qual a taxa de download que foi obtida ?
  • Como se desempenhou a reprodução do video ?


A reprodução do video poderia ser preservada se a rede priorizasse seu tráfego. Assim, uma forma de priorização será definida no gateway do laboratório. Após essa modificação, repitam os downloads do arquivo e reprodução do video.

  • Qual a nova taxa de download obtida ?
  • Como se desempenhou a reprodução do video desta vez ?

Uma outra experiência

Desta vez, todos irão usar softphones (ou telefones IP) para escutar uma mensagem gravada em um servidor fora da rede, ao mesmo tempo em que se descarrega um arquivo via HTTP:

  1. Execute o Jitsi ou use um telefone IP, registrando-o em 192.168.2.1 com o ramal 2000+número_do_seu_computador (com senha=ramal).
  2. Faça este download:
    wget http://172.18.200.251/~msobral/rmu.bin
  3. Execute o wireshark, e deixe-o capturando datagramas UDP na interface eth0.
  4. Chame o ramal 6666, e escute a mensagem gravada.
  5. Ao final da chamada, veja a qualidade da stream RTP no wireshark, acessando o menu Telephony->RTP->Show All Streams.

Novamente, as chamadas poderiam ser preservadas se a rede priorizasse seu tráfego. Para isso, foi reativada a priorização de datagramas UDP no gateway do laboratório. Após essa modificação, repitam os downloads do arquivo e realização das chamadas.

  • Qual a nova taxa de download obtida ?
  • Que qualidade se obteve para as streams RTP desta vez ?

29/11: Provendo QoS: conceitos básicos

Como PROVER qualidade de serviço em uma rede ?

  • Como classificar os pacotes, para que sejam tratados de acordo com os requisitos de QoS especificados ?
  • Como garantir banda para um determinada classe de tráfego ?
  • Como limitar o uso de banda ?
  • Como limitar o atraso fim-a-fim de pacotes ?
  • Como limitar a variação de atraso (jitter) de pacotes ?

Assume-se que a rede considerada seja formada por uma malha de roteadores. Cada interface de um roteador possui uma fila de saída, onde ficam os pacotes à espera de serem transmitidos, como mostrado na figura a seguir. Essas filas possuem tamanho limitado, sendo implementadas por buffers de memória. Para prover QoS, uma primeira necessidade é controlar quando saem pacotes por uma interface (para limitar banda), e a ordem em que pacotes saem (para priorizar pacotes, garantir banda e limitar atrasos). Isso significa atuar principalmente sobre as filas de saída das interfaces de rede.

Filas-roteador.png


Algumas técnicas conhecidas podem ser usadas para atender os requisitos acima:

  • Classificador: classifica os pacotes em classes de serviço, de acordo com contratos de tráfego predefinidos. Atua na entrada de pacotes no roteador.
  • Disciplinas de filas: trata de definir a ordem de saída de pacotes. Com isso se consegue implementar garantia de banda mínima, priorização de tráfego, redução de atraso fim-a-fim e variação de atraso.
  • Balde furado (leaky bucket): trata de definir quando pacotes podem sair. Com isso se pode fazer limitação de banda. Esta é uma técnica fundamental para fazer condicionamento de tráfego (traffic shaping);.


A combinação dessas técnicas possibilita atender os requisitos de QoS especificados para diferentes tipos de tráfego. Elas são amplamente usadas em arquiteturas para QoS na Internet, tais como Intserv e Diffserv.

Exercícios

Resolver os exercícios propostos no final das transparências.

04/12: Avaliação 1

A avaliação 1 cobrirá os assuntos estudados até dia 20/11.

Os exercícios do capítulo 7 do livro "Redes de Computadores e a Internet, 5a edição", do Kurose, devem ser resolvidos:

  1. Exercicios de fixação: 1, 2, 4, 5, 6, 7, 9, 10, 11, 12
  2. Problemas: 1, 3, 4, 5, 7, 8, 9, 10, 12, 13, 14, 16, 17, 18, 19

É possível que haja questões na avaliação sobre o uso do Asterisk, envolvendo definição de canais SIP e plano de discagem.

Vejam as provas feitas em semestres anteriores:

06/12: Simulação com Opnet

Hoje serão feitos experimentos com o simulador de redes Opnet. Esses experimentos mostrarão os descartes de pacotes, além de atrasos de entrega e variação de atraso, para diferentes disciplinas de enfileiramento nos roteadores.



Obs: deve-se usar o Crossover para rodar o simulador no Ubuntu 10.04. Para facilitar iniciar o simulador, salve o script abaixo na sua área de trabalho. Use-o para excutar o simulador.


Rmu-opnet.png


Os modelos de simulação criados ficam localizados em: 

.cxoffice/Unsupported/drive_c/windows/temp/op_models

Assim, pode-se fazer um backup dos modelos caso necessário.

TAREFA: leitura de um texto

Leiam este texto sobre um problema relacionado aos atrasos de transmissão percebidos na Internet:

Na aula de 3a feira (11/12) sortearei um aluno para explicar o conteúdo desse artigo.


11/12: QoS em um roteador Linux

Disciplinas de filas (qdisc)

Disciplinas de filas são mecanismos para condicionar a saída de pacotes por uma interface de rede. Com elas se podem priorizar pacotes e limitar taxas de bits de fluxos de saída.

Rmu-Qdisc-overview.png
Visão geral do enfileiramento de pacotes em uma interface de saída

As filas contidas nas qdisc podem ser tratadas de diferentes formas. Isso vai determinar a ordem e o ritmo com que os pacotes são desenfileirados para serem transmitidos. Alguns exemplos de qdisc implementadas no Linux:

Os diagramas abaixo ilustram algumas dessas qdisc:

Rmu-Prio-qdisc.gif
Uma disciplina de filas baseada em prioridades. Fonte: Differentiated Service on Linux HOWTO


Rmu-Tbf-qdisc.gif
A qdisc TBF (combinada com PRIO), usada para limitar a taxa de saída. Fonte: Differentiated Service on Linux HOWTO


Rmu-Dsmark.gif
A qdisc DSMARK, usada em uma estrutura Diffserv com Linux. Fonte: Differentiated Service on Linux HOWTO

Atividade

Os exercícios sobre disciplinas de filas serão realizados em um cenário em que dois tipos de fluxo são estabelecidos entre duas redes, que estão interligadas por um link ponto-a-ponto. Esse link tem capacidade limitada a 512 kbps. Os fluxos são representados por:

  • Uma transferência de um arquivo com HTTP
  • Uma chamada VoIP com SIP e RTP

Rede-qos-rtp.png


A rede a ser usada deve ser criada no Netkit, a partir da configuração abaixo:


Arquivo de configuração do Netkit (copie-o para dentro de Lab.conf) 
# Global attributes: these values are obtained automatically from menu General->Preferences
global[mem]=32
global[compact]=False
global[vm]=0
global[clean]=False
# 32 MB por VM
# Não remove o diretório de trabalho ao final da execução

server1[type]=generic
server2[type]=generic
pc[type]=generic
r1[type]=gateway
r2[type]=gateway

# Rede 1: servidores + roteador r1
server1[eth0]=rede1:ip=192.168.1.1/24
server2[eth0]=rede1:ip=192.168.1.2/24
r1[eth0]=rede1:ip=192.168.1.254/24

# Rede 2: pc + roteador r2
r2[eth0]=rede2:ip=192.168.2.254/24
pc[eth0]=rede2:ip=192.168.2.1/24

# Link PPP entre Rede 1 e Rede 2 (512 kbps)
r1[eth1]=link:ip=10.0.0.1/30
r2[eth1]=link:ip=10.0.0.2/30

# Roteadores default dos servidores e pc
server1[default_gateway]=192.168.1.254
server2[default_gateway]=192.168.1.254
pc[default_gateway]=192.168.2.254

# Rotas estáticas nos roteadores
r1[route]=192.168.2.0/24:gateway=10.0.0.2
r2[route]=192.168.1.0/24:gateway=10.0.0.1

# Ativando o servidor HTTP em server1
server1[services]=apache2

Roteiro

1) As chamadas VoIP serão simuladas usando uma ferramenta de teste chamada siprtp, que faz parte do projeto PJSIP. Seu uso deve ser da seguinte forma:

  • Em server2 executa-se o siprtp em modo servidor: 
    siprtp --ip-addr=192.168.1.2
  • Em um dos roteadores deve-se executar o wireshark (ver menu Wireshark), escolhendo-se a interface eth0.
  • Em pc executa-se o siprtp em modo cliente, de forma a efetuar uma chamada para server2: 
    siprtp --ip-addr=192.168.2.1 sip:0@192.168.1.2
  • Em pc pode-se monitorar o andamento da chamada teclando-se l. Um sumário como mostrado abaixo deve ser apresentado: 
    >>> l
List all calls:
Call #0: CONFIRMED [duration: 00:00:01.643]
   To: sip:0@127.0.1.1;tag=PKcMBzp6yhIZQG-du1TsYkW1MPmX6L5V
   Signaling quality: got 1st response in 0 ms, connected after: 0 ms
   Stream #0: audio PCMU@8000Hz, 20ms/frame, 8.00KB/s (9.06KB/s +IP hdr)
              RX stat last update: never
                 total 77 packets 12.03KB received (14.07KB +IP hdr)
                 pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
                       (msec)    min     avg     max     last
                 loss period:   0.000   0.000   0.000   0.000
                 jitter     :   0.000   0.000   0.000   0.000
              TX stat last update: never
                 total 77 packets 12.03KB sent (14.07KB +IP hdr)
                 pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
                       (msec)    min     avg     max     last
                 loss period:   0.000   0.000   0.000   0.000
                 jitter     :   0.000   0.000   0.000   0.000
             RTT delay      :   0.000   0.000   0.000   0.000
  • A cada vez que se teclar l, um novo sumário pode ser visualizado.
  • Quando se quiser encerrar a chamada, deve-se teclar h, e em seguida fornecer o número da chamada (0 - zero).
  • Após o término da chamada, recarregar os pacotes no wireshark (tecle no ícone para forçar a atualização). Em seguida selecione Telephony->VoIP Calls e visualize a chamada realizada. Experimente também selecionar Telephony->RTP->Show All streams e analisar a stream RTP da chamada. Observe particularmente os valores para delta e jitter.

2) O experimento da realização da chamada VoIP deve ser repetido, porém realizando-se também uma transferência de arquivo com HTTP entre server1 e pc:

  • Crie um arquivo de 16 MB em server1: 
    dd if=/dev/urandom of=/var/www/teste.img bs=4096 count=4096
  • Inicie seu download em pc: 
    wget http://192.168.1.1/teste.img > log 2>&1 &
  • Repita os passos do ítem 1, prestando especial atenção aos valores de jitter e perda de pacotes mostrados no sumário de chamada do siprtp. Compare aos valores obtidos quando foi realizada somente a chamada VoIP.

3) Chamadas VoIP são consideradas prioritárias em comparação a transferências de arquivos (e fluxos de dados em geral), pois possuem restrições de atrasos e jitter. Assim, devem ser definidas qdisc nos roteadores para priorizar pacotes RTP. Isso pode ser feito assim:

  • Em r1 e r2 cria-se uma qdisc do tipo prio na interface ppp0. Os fluxos UDP com port 4000 (stream RTP criada pelo siprtp) devem ser colocados na fila de maior prioridade. Copie os comandos abaixo para dentro do arquivo lab/shared/qdisc.sh:
    #!/bin/bash

# Limpa as qdisc que porventura existam
tc qdisc del dev eth1 root
 
# Cria uma qdisc HTB (Hierarchical Token Bucket) para limitar a saída a uma taxa comparável 
# a do link ponto-a-ponto
tc qdisc add dev eth1 root handle 1: htb default 1
tc class add dev eth1  parent 1: classid 1:1 htb rate 256kbit ceil 256kbit
 
# Cria uma qdisc PRIO, porém subordinada a qdisc TBF
tc qdisc add dev eth1 parent 1:1 handle 10:0 prio
 
# Datagramas UDP vão pra fila mais prioritária.
tc filter add dev eth1 parent 10: prio 1 protocol ip u32 match ip protocol 17 0xff flowid 10:1

# Segmentos TCP vão pra fila menos prioritária.
tc filter add dev eth1 parent 10: prio 1 protocol ip u32 match ip protocol 6 0xff flowid 10:2
  • Repita o ítem 2, e observe as perdas de pacotes e jitter da chamada VoIP. Houve melhora ?

4) Pela capacidade do link é possível haver mais de uma chamada VoIP. Sendo assim:

  • Calcule quantas chamadas podem ser atendidas através desse link.
  • Teste se de fato essa quantidade de chamadas pode ser atendida, respeitando-se seus requisitos de QoS. Para iniciar mais de uma chamada simultânea execute o siprtp da seguinte forma: 
    # inicia duas chamadas
siprtp --ip-addr=192.168.2.1 --count=2


13/12: QoS em roteador Linux

qdisc com estado (stateful)

Com exceção da qdisc PRIO, até o momento foram vistas somente qdisc capazes de conter uma única classe. Regras de priorização e condicionamento de tráfego mais elaboradas precisam, no entanto, combinar qdisc hierarquicamente. Isso pode ser percebido com um primeiro exemplo.

Em um enlace, deseja-se limitar em 100 kbps o tráfego de um conjunto de aplicações. No entanto, cada aplicação também deve ter um limite de uso do enlace, de acordo com o descrito a seguir:

  • WWW (http e https): 40 kbps
  • SSH: 40 kbps
  • Demais aplicações: 20 kbps


O diagrama abaixo mostra como poderia ser modelada a limitação de banda para essas aplicações:


Qdisc-ex1.png


Como isso poderia ser feito usando o tc ? Usando apenas as qdisc que já vimos não parece possível implementar essa regras (na dúvida, você pode tentar). Mas se for usada uma qdisc capaz de conter várias classes, isso poderia ser realizado. Essa qdisc limitaria o uso de banda a 100 kbps, e dentro dela existiriam três classes (uma para cada tipo de aplicação). Cada classe, por sua vez, conteria uma qdisc que poderia impor sua limitação de banda específica. E é exatamente isso que a qdisc HTB (Hierarchical Token Bucket) é capaz de fazer, criando uma hierarquia de classes e qdisc como mostrado na figura abaixo:


Qdisc-ex1-diagram.png 


# adiciona a qdisc raiz na interface eth0
tc qdisc add dev eth0 root handle 1:0 htb default 23

# cria a classe filha, que impõe o limite de banda global desta HTB
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100kbps ceil 100kbps

# cria as classes das aplicações
tc class add dev eth0 parent 1:1 classid 1:21 htb rate 40kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:22 htb rate 40kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:23 htb rate 20kbps ceil 100kbps

# cria os filtros para classificar os datagramas
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 80 0xffff flowid 1:21
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 443 0xffff flowid 1:21
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 22 0xffff flowid 1:22

A qdisc HTB funciona da seguinte forma:

  • Cada classe possui uma taxa garantida e uma taxa máxima.
  • A banda garantida não utilizada por uma classe reverte para para sua classe mãe (um nível acima na hierarquia). Essa sobra pode assim ser aproveitada pelas outras classes filhas.
  • Cada classe pode emprestar banda adicional de sua classe mãe até o limite especificado por sua taxa máxima.
  • Se houver mais de uma classe filha requisitando banda adicional, a classe mãe divide essa banda proporcionalmente à taxa garantida de cada filha.
  • Classes podem ter prioridades, de forma que classes mais prioritárias se apropriam primeiro da banda de sobra (mas a taxa garantida é preservada).


Os parâmetros da qdisc HTB estão sumarizados abaixo:

Parâmetro Descrição Exemplo
rate taxa garantida rate 100kbit
ceil taxa máxima ceil 200 kbit
prio prioridade da classe (menores valores = maiores prioridades) prio 1
burst quantidade máxima de bytes de uma classe, dentro da taxa garantida,
que podem ser enviados antes de servir outra classe		 burst 20 kb
cburst quantidade máxima de bytes de uma classe, acima da taxa garabntida,
que podem ser enviados antes de servir outra classe		 cburst 20 k

Atividade

A rede abaixo será usada para os experimentos com disciplinas de enfileiramento:


Rede-qos-rtp2.png


Configuração para o Netkit (salvar em Lab.conf) 
# Global attributes: these values are obtained automatically from menu General->Preferences
# 32 MB por VM
global[mem]=32
# Não remove o diretório de trabalho ao final da execução
global[clean]=False
 
server1[type]=generic
server2[type]=generic
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic
r1[type]=gateway
r2[type]=gateway
 
# Rede 1: servidores + roteador r1
server1[eth0]=rede1:ip=192.168.1.1/24
server2[eth0]=rede1:ip=192.168.1.2/24
r1[eth0]=rede1:ip=192.168.1.254/24
 
# Rede 2: pc + roteador r2
r2[eth0]=rede2:ip=192.168.2.254/24
pc1[eth0]=rede2:ip=192.168.2.1/24
pc2[eth0]=rede2:ip=192.168.2.2/24
pc3[eth0]=rede2:ip=192.168.2.3/24
 
# Link PPP entre Rede 1 e Rede 2 (512 kbps)
r1[eth1]=link:ip=10.0.0.1/30
r2[eth1]=link:ip=10.0.0.2/30
 
# Roteadores default dos servidores e pc
server1[default_gateway]=192.168.1.254
server2[default_gateway]=192.168.1.254
pc1[default_gateway]=192.168.2.254
pc2[default_gateway]=192.168.2.254
pc3[default_gateway]=192.168.2.254
 
# Rotas estáticas nos roteadores
r1[route]=192.168.2.0/24:gateway=10.0.0.2
r2[route]=192.168.1.0/24:gateway=10.0.0.1
 
# Ativando o servidor HTTP em server1
server1[services]=apache2:netserver

1) Na rede usada nos exercícios da semana passada, procuravam-se priorizar as chamadas VoIP usando uma qdisc PRIO. Modifique a disciplina de enfileiramento nos roteadores para que até 2 chamadas possam ser realizadas simultaneamente (com seus requisitos de QoS atendidos). Use a qdisc HTB.

  • Qual a banda disponível para as transferências de dados no melhor e no pior caso ? Descubra isso por meio de um experimento na rede simulada (você pode usar o netperf).
Regras para criar as disciplinas de filas 
#!/bin/bash

IFACE=eth1

tc qdisc del dev $IFACE root

# adiciona a qdisc raiz na interface eth0
tc qdisc add dev $IFACE root handle 1:0 htb default 22

# cria a classe filha, que impõe o limite de banda global desta HTB
tc class add dev $IFACE parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit

# cria as classes das aplicações
tc class add dev $IFACE parent 1:1 classid 1:21 htb rate 180kbit ceil 512kbit
tc class add dev $IFACE parent 1:1 classid 1:22 htb rate 1bps ceil 512kbit

# cria os filtros para classificar os datagramas
tc filter add dev $IFACE protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff flowid 1:21

2) Modifique as regras de QoS do exercicio 1 de forma que:

  • pc1 tenha garantidos 256 kbps, com garantia de QoS para uma chamada VoIP.
  • pc2 tenha garantidos 256 kbps, com garantia de QoS para duas chamadas VoIP.
  • pc3 não tenha banda garantida, mas possa usar a banda ociosa.

3) Incremente as regras de QoS do exercício 2 para que tráfego SSH tenha prioridade em relação aos demais tipos de tráfego de dados.

4) Em relação ao exercício 3, ao invés de priorizar SSH modifique as regras para que se garanta ao menos 64 kbps para esse tipo de tráfego.

5) A disciplina de filas WFQ, existente em roteadores Cisco e usada para garantir banda para classes de serviço, não está implementada no controle de tráfego do Linux. Com as disciplinas existentes no Linux seria possível emular a WFQ ? Caso sim, como isso poderia ser feito ?

  • Por exemplo, como emular WFQ de forma que chamadas VoIP tenham peso 5, tráfego SSH tenha peso 2, e demais tipos de tráfego tenha peso 3 ?
  • Como se poderia resolver o exercício 2 caso se usasse WFQ ?


18/12: Exercícios

Sobre disciplinas de filas e QoS.

OBS: lista para a avaliação 2: exercícios 20 a 28 do cap. 7 do livro Redes de Computadores e a Internet, 5a edição, de James Kurose.

20/12: Avaliação 2

05/02: Diffserv em roteador Linux

Diffserv é um modelo para provimento de QoS para Internet, em que fluxos são classificados e então tratados de forma diferenciada dentro da rede. A proposta, contida na RFC 2475, visa definir um modelo flexível e escalável para atendimento de requisitos de QoS.

  • Flexibilidade: o tratamento de cada classe de tráfego é uma decisão da gerência da rede, e assim não é especificada na proposta.
  • Escalabilidade: a priorização e condicionamento de tráfego a serem feitos nos roteadores se basearão nas classes de tráfego, e não nos fluxos individuais que passam pela rede (compare com IntServ). Isso proporciona a agregação dos fluxos, que são rotulados com as classes de serviço, facilitando a tarefa dos roteadores no núcleo da rede.
Obs: as figuras abaixo foram obtidas em um artigo da Cisco


Uma visão geral da arquitetura DiffServ pode ser vista na figura abaixo:


Diffserv-arch.png
Arquitetura DiffServ


Diversos elementos compõem a arquitetura:

  • Domínios DiffServ: conjuntos de roteadores onde se aplicam uma determinada classificação e diferenciação de tráfego, definidas pela gerência da rede.
  • Roteadores de borda: roteadores que classificam fluxos que entram num domínio DiffServ. Essa tarefa de classificação e condicionamento de fluxos de entrada pode ser complexa. Por esses roteadores também passam fluxos que saem do domínio, para serem entregues a sistemas finais.
  • Roteadores de núcleo: roteadores internos de um domínio DiffServ, que encaminham fluxos já classificados. Esses roteadores verificam a conformidade desses fluxos às regras definidas pela gerência da rede para as classes de serviço. Assim, pacotes desses fluxos estão sujeitos a priorizações, enfileiramentos, e mesmo descartes, dependendo das restrições de QoS que foram definidas. Essas regras compõem o que se chama de Comportamento por Salto (PHB - Per-Hop Behaviour), representada no diagrama contido na figura abaixo.


Diffserv-tcb.png
PHB - Per-Hop Behaviour


A classificação feita nos roteadores de borda mapeia características dos fluxos para um número de 6 bits. Assim, podem haver até 64 classes de serviço em um domínio DiffServ. Esse número, chamado de DSCP - DiffServ Code Point, é inscrito no campo ToS dos datagramas IPv4 (ou no campo Traffic Class de datagramas IPv6), como mostrado abaixo:

Ip-tos.png Dscp.png


Os comportamentos por salto podem ser:

  • Default PHB: pacotes com DSCP de valor 000000 (zero) são tratados com melhor esforço. Isso também deve ser aplicado para pacotes cujos DSCP tenham valores não reconhecidos pelo roteador. Ver maiores detalhes na RFC 2474.
  • Class-selector PHB: pacotes com DSCP xxx000 são tratados de acordo com uma política tradicional de precedência IP (i.e. classes de tráfego descritas no campo ToS). Também descrito na RFC 2474
  • Expedited Forwarding PHB (EF): semelhante ao serviço garantido do IntServ. Desenhado para prover um serviço com baixas taxas de perda, baixa latência e jitter, e uma largura de banda garantida. Deve ser usado somente por aplicações críticas. O valor do DSCP deve ser 10110 (ver RFC 2598
  • Assured Forwarding PHB (AF): semelhante ao serviço de carga controlada do IntServ. Define quatro classes de serviço, sendo que cada uma tem três níveis de precedência de descarte.


Aff-codepoint-table.png
Classes de serviço e precedências de descarte em AF PHB

Uma interpretação sobre Diffserv

Um domínio DiffServ é composto por roteadores com comportamentos predefinidos (PHB - Per Host Behavior), e que policiam e condicionam fluxos de acordo com as classes de tráfego existentes. Dentre os quatro grupos de classes, vale destacar estes dois:

  • Encaminhamento Acelerado (Expedited Forwarding - EF): proporciona baixo atraso, baixo jitter, baixa perda de pacotes. Uma boa discussão sobre esse PHB pode ser encontrada aqui.
    • Principal característica: definir um limite superior para atraso de encaminhamento em um nodo, assumindo que a fila de saída esteja usualmente vazia ou seja curta.
    • Finalidade: atender fluxos que necessitam de atrasos e jitter estritos.
      De acordo com a RFC 3246: 
      Intuitively, the definition of EF is simple: the rate at which EF
traffic is served at a given output interface should be at least the
configured rate R, over a suitably defined interval, independent of
the offered load of non-EF traffic to that interface.
      ... e complementado pela RFC 3248:
      For a traffic stream not exceeding a configured rate the goal of the
DB PHB is a strict bound on the delay variation of packets through a
hop.

Traffic MUST be policed and/or shaped at the source edge (for
example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in
order to get such a bound.  However, specific policing and/or shaping
rules are outside the scope of the DB PHB definition.  Such rules
MUST be defined in any per-domain behaviors (PDBs) composed from the
DB PHB.
  • Encaminhamento Assegurado (Assured Forwarding - AF): oferece diferentes probabilidades de que pacotes sejam encaminhados.
    • Principal característica: a probabilidade de que pacotes sejam encaminhados depende dos recursos alocados (buffer e largura de banda) para cada classe AF e respectivas precedências de descartes em caso de congestionamento.
    • Finalidade: limitar a vazão de fluxos, respeitando rajadas em certa medida.
      De acordo com a RFC 2597:
      In a DS node, the level of forwarding assurance of an IP packet thus
depends on (1) how much forwarding resources has been allocated to
the AF class that the packet belongs to, (2) what is the current load
of the AF class, and, in case of congestion within the class, (3)
what is the drop precedence of the packet.

As outras classes são Default PHB, que corresponde a um serviço melhor esforço, e Class Selector PHB, que se baseia na interpretação convencional do campo ToS do cabeçalho IP.

A implantação de um domínio DiffServ usando roteadores Linux implica usar as regras de controle de tráfego do Linux (via utilitários tc e iptables) para criar essas classes. Para isso precisamos ter claro o seguinte:

  • Como policiar tráfego que entra em um domínio DiffServ ?
  • Como modificar o campo DSCP de datagramas IP, e como usar o valor desse campo para identificar uma classe de tráfego ?
  • Como limitar atrasos de encaminhamento ?
  • Como garantir banda a um fluxo agregado, com certa tolerância a rajadas ?
  • Como fazer descartes com diferentes probabilidades e precedências ?

Marcação DiffServ

No DiffServ, o campo DSCP de datagramas IP é usado para indicar a classe a que pertence cada datagrama. Com base nesse valor, cada roteador pode aplicar seu PHB e assim condicionar o tráfego. Existem duas formas de marcar o campo DSCP e usar esse valor para classificação:

  1. Usando o tc: isso pode ser feito diretamente com o tc, por meio de uma qdisc especial chamada DSMARK combinada a filtros. Essa forma de marcar e classificar datagramas é um pouco mais complexa, como se pode ver por este exemplo: 
    # Cria a qdisc DSMARK com 64 índices. 
tc qdisc add dev eth0 handle 1:0 root dsmark indices 64 set_tc_index

# Cria uma classe DSMARK para definir o valor do DSCP para 0xb8
tc class change dev eth0 classid 1:1 dsmark mask 0x3 value 0xb8
    ... e para escolher uma classe dependendo do valor DSCP:
    # Filtro que usa o valor do DSCP para calcular o valor do handle de outro filtro. Quer dizer, 
# este filtro serve apenas para selecionar outro filtro.
tc filter add dev eth0 parent 1:0 protocol ip prio 1 tcindex mask 0xfc  shift 2

# Uma qdisc HTB com taxa de 100 kBps e duas classes .. apenas para exemplificar o uso do filtro tc_index mais abaixo
tc qdisc add dev eth0 parent 1:0 handle 2:0 htb default 13
tc class add dev eth0 parent 2:0 classid 2:1 htb rate 100kbps ceil 100kbps
tc class add dev eth0 parent 2:1 classid 2:12 htb rate 80kbps ceil 100kbps
tc class add dev eth0 parent 2:1 classid 2:13 htb rate 20kbps ceil 100kbps

# O filtro ao final selecionado escolhe a classe a receber o pacote. Esse filtro está vinculado a uma qdisc
# com handle 2:0, e se ativado classifica o datagrama na classe 2:12. O handle do filtro (0x2e) é o resultado do cálculo 
# feito pelo filtro tc_index sobre o campo DSCP ... simples, não ?
tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 0x2e tcindex classid 2:12 pass_on
    ... simples, não ???
  2. Usando o iptables: na tabela mangle usa-se o alvo DSCP para marcar os datagramas. Para associar um datagrama a uma classe, de acordo com o valor DSCP, deve-se usar o módulo dscp e os alvos CLASSIFY ou MARK. Ex: 
    # Uma qdisc HTB com taxa de 100 kBps e duas classes .. apenas para exemplificar o uso do iptables mais abaixo
tc qdisc add dev eth0 root handle handle 1:0 htb default 13
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 80kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbps ceil 100kbps

# marca os datagramas vindos da rede 172.18.0.0/16 na classe AF41
iptables -t mangle -A PREROUTING -s 172.18.0.0/16 -j DSCP --set-dscp-class af41

# datagramas da classe DSCP AF41 vão para a classe 1:21 do tc
iptables -t mangle -A FORWARD -m dscp --dscp-class af41 -j CLASSIFY --set-class 1:12

Policiamento de tráfego

O policiamento de tráfego ocorre na recepção de pacotes por um roteador. Essa função é responsável por assegurar que os pacotes estejam dentro de limites definidos para sua classe. Caso um pacote não satisfaça a condição de policiamento, pode ser descartado ou reclassificado como melhor esforço. Assim, evita-se que fluxos com taxas maiores que a contratada entrem no roteador. Porém isso funciona plenamente somente com a qdisc CBQ, que por ser muito complexa não foi estudada aqui. De qualquer forma, filtros com policiamento podem ser usados para limitar tráfego de entrada usando a qdisc especial ingress. Essa qdisc não possui parâmetros, pois seu propósito é somente conter filtros para fins de policiamento. Seu funcionamento é limitado, pois provê apenas duas possibilidades: aceitar ou descartar pacotes.

Exemplo: 

# Cria a qdisc ingress
tc qdisc add dev eth0 ingress

# Limita o tráfego de entrada vindo de 172.18.0.0/16 a 100kbps, descartando o que exceder esse limite.
tc filter add dev eth0 parent ffff: protocol ip u32 match ip src 172.18.0.0/16 police rate 100kbps buffer 10k drop flowid :1

TAREFA: Leitura da semana

Leiam até a seção 3.2 (inclusive) deste texto sobre MPLS e Diffserv e preparem-se para apresentá-lo na aula da 5a feira - 14/02:

07/02: DiffServ em roteador Linux (continuação)

Atividade

Um pequeno provedor possui uma rede como mostrado abaixo. Essa rede é usada para interligar seus clientes, no caso as empresas Ajax e Tabajara.


Diffserv-rede1.png

Configuração para o Netkit 
B1[type]=gateway
B2[type]=gateway
N1[type]=gateway
Ajax1[type]=generic
Ajax2[type]=generic
Tabajara1[type]=generic
Tabajara2[type]=generic

# Preservando o script que cria as regras de QoS nos roteadores.
# OBS: não esqueça de exportar o projeto do Netkit após terminar a execução da rede ! Ver menu File->Export ...
B1[preserve]=/root/firewall.sh
B2[preserve]=/root/firewall.sh
N1[preserve]=/root/firewall.sh

# Links ...
B1[eth0]=link1:ip=192.168.0.254/24
B1[eth1]=link2:ip=192.168.10.254/24
B1[eth2]=link3:ip=10.0.0.1/28

N1[eth0]=link3:ip=10.0.0.2/28
N1[eth1]=link4:ip=10.0.0.18/28

B2[eth0]=link5:ip=192.168.1.254/24
B2[eth1]=link6:ip=192.168.11.254/24
B2[eth2]=link4:ip=10.0.0.17/28

Ajax1[eth0]=link1:ip=192.168.0.1/24
Ajax2[eth0]=link5:ip=192.168.1.1/24

Tabajara1[eth0]=link2:ip=192.168.10.1/24
Tabajara2[eth0]=link6:ip=192.168.11.1/24

# Rotas ...
Ajax1[default_gateway]=192.168.0.254
Ajax2[default_gateway]=192.168.1.254
Tabajara1[default_gateway]=192.168.10.254
Tabajara2[default_gateway]=192.168.11.254
B1[default_gateway]=10.0.0.2
B2[default_gateway]=10.0.0.18
N1[route]=192.168.0.0/24:gateway=10.0.0.1
N1[route]=192.168.10.0/24:gateway=10.0.0.1
N1[route]=192.168.1.0/24:gateway=10.0.0.17
N1[route]=192.168.11.0/24:gateway=10.0.0.17

Para implantar a estrutura DiffServ, deve-se começar com o seguinte:

i) Os roteadores de borda (B1 e B2) devem ser capazes de marcar, policiar e condicionar os datagramas dos clientes. A marcação deve ser feita de acordo com as classes de serviço escolhidas em cada caso.

ii) O roteador de núcleo (N1) deve ter um PHB capaz de atender tanto classes do tipo Encaminhamento Assegurado (AF) quanto Encaminhamento Acelerado (EF). A diferenciação nesse roteador deve ser feita de acordo com a marcação contida nos datagramas - e que foi realizada nos roteadores de borda.

OBS: os links dentro da rede do provedor estão superdimensionados, portanto não apresentam gargalos.
OBS 2: para medir os atrasos de transmissão pode-se usar este programa. Ele fornece uma estimativa dos atrasos médios, máximo, mínimo e jitter.
OBS 3: a marcação dos datagramas IP deve ser feita via Netfilter, cujas regras devem ser criadas por meio do utilitário iptables. A classificação dos datagramas pode ser feita tanto com iptables quanto com tc.

Tendo a estrutura inicial preparada, resolva os seguintes problemas:


1) O cliente Ajax contratou um link de 1 Mbps, e Tabajara contratou um link de 2 Mbps. Em ambos os casos, os links são simétricos. Implemente uma estrutura DiffServ nesse provedor, assumindo que ambos clientes usem classes do tipo Encaminhamento Assegurado (AF).

2) O cliente Ajax precisa usar parte da capacidade contratada para transmitir streams de audio (voz). Assumindo que as streams estarão codificadas com codec Speex em modo WB (Wide Band), e que pode haver até 5 streams simultâneas, use a sua estrutura DiffServ para atender essa necessidade.

3) O cliente Tabajara precisa transmitir streams de audio e videoconferência. Assumindo que possam haver até 4 streams de audio simultâneas, codificadas com Speex em modo NB (Narrow Band), e a stream de video use 256 kbps, use a estrutura DiffServ para atender essa demanda.

14/02: DiffServ em roteador Linux (continuação)

Para concluir o estudo sobre Diffserv, será feito um projeto com esta outra rede:

Diffserv-rede2.png


Configuração para o Netkit 
B1[type]=gateway
B2[type]=gateway
B3[type]=gateway
B4[type]=gateway
N1[type]=gateway
N2[type]=gateway
N3[type]=gateway
N4[type]=gateway
Ajax1[type]=generic
Ajax2[type]=generic
Tabajara1[type]=generic
Tabajara2[type]=generic
Lexcorp1[type]=generic
Lexcorp2[type]=generic
 
# Preservando o script que cria as regras de QoS nos roteadores.
# OBS: não esqueça de exportar o projeto do Netkit após terminar a execução da rede ! Ver menu File->Export ...
B1[preserve]=/root/firewall.sh
B2[preserve]=/root/firewall.sh
B3[preserve]=/root/firewall.sh
B4[preserve]=/root/firewall.sh
N1[preserve]=/root/firewall.sh
N2[preserve]=/root/firewall.sh
N3[preserve]=/root/firewall.sh
N4[preserve]=/root/firewall.sh
 
# Links ...
B1[eth0]=link-ajax1:ip=192.168.1.254/24
B1[eth1]=link-b1-n1:ip=10.0.0.1/30
B2[eth0]=link-tab2:ip=192.168.12.254/24
B2[eth1]=link-lex1:ip=192.168.21.254/24
B2[eth2]=link-b2-n2:ip=10.0.0.5/30
B3[eth0]=link-tab1:ip=192.168.11.254/24
B3[eth1]=link-b3-n3:ip=10.0.0.9/30
B4[eth0]=link-ajax2:ip=192.168.2.254/24
B4[eth1]=link-lex2:ip=192.168.22.254/24
B4[eth2]=link-b4-n4:ip=10.0.0.13/30
 
N1[eth0]=link-b1-n1:ip=10.0.0.2/30
N1[eth1]=link-n1-n2:ip=10.0.0.17/30
N1[eth2]=link-n1-n3:ip=10.0.0.21/30
 
N2[eth0]=link-b2-n2:ip=10.0.0.6/30
N2[eth1]=link-n1-n2:ip=10.0.0.18/30
N2[eth2]=link-n2-n4:ip=10.0.0.25/30
 
N3[eth0]=link-b3-n3:ip=10.0.0.10/30
N3[eth1]=link-n1-n3:ip=10.0.0.22/30
N3[eth2]=link-n3-n4:ip=10.0.0.29/30
 
N4[eth0]=link-b4-n4:ip=10.0.0.14/30
N4[eth1]=link-n2-n4:ip=10.0.0.26/30
N4[eth2]=link-n3-n4:ip=10.0.0.30/30
 
Ajax1[eth0]=link-ajax1:ip=192.168.1.1/24
Ajax2[eth0]=link-ajax2:ip=192.168.2.1/24
 
Tabajara1[eth0]=link-tab1:ip=192.168.11.1/24
Tabajara2[eth0]=link-tab2:ip=192.168.12.1/24
 
Lexcorp1[eth0]=link-lex1:ip=192.168.21.1/24
Lexcorp2[eth0]=link-lex2:ip=192.168.22.1/24
 
# Rotas ...
Ajax1[default_gateway]=192.168.1.254
Ajax2[default_gateway]=192.168.2.254
Tabajara1[default_gateway]=192.168.11.254
Tabajara2[default_gateway]=192.168.12.254
Lexcorp1[default_gateway]=192.168.21.254
Lexcorp2[default_gateway]=192.168.22.254
B1[default_gateway]=10.0.0.2
B2[default_gateway]=10.0.0.6
B3[default_gateway]=10.0.0.10
B4[default_gateway]=10.0.0.14
 
# Ajax1 <-> Ajax2
N1[route]=192.168.1.0/24:gateway=10.0.0.1
N1[route]=192.168.2.0/24:gateway=10.0.0.18
N2[route]=192.168.1.0/24:gateway=10.0.0.17
N2[route]=192.168.2.0/24:gateway=10.0.0.26
N4[route]=192.168.1.0/24:gateway=10.0.0.25
N4[route]=192.168.2.0/24:gateway=10.0.0.13
 
# tab1 <-> tab2
N3[route]=192.168.11.0/24:gateway=10.0.0.9
N3[route]=192.168.12.0/24:gateway=10.0.0.30
N4[route]=192.168.11.0/24:gateway=10.0.0.29
N4[route]=192.168.12.0/24:gateway=10.0.0.25
N2[route]=192.168.11.0/24:gateway=10.0.0.26
N2[route]=192.168.12.0/24:gateway=10.0.0.5
 
# Lex1 <-> Lex2
N2[route]=192.168.21.0/24:gateway=10.0.0.5
N2[route]=192.168.22.0/24:gateway=10.0.0.26
N4[route]=192.168.21.0/24:gateway=10.0.0.25
N4[route]=192.168.22.0/24:gateway=10.0.0.13

Nessa rede deve-se implantar um serviço do tipo Olímpico. Esse serviço é composto por três classes:

  • Ouro: provê links de 2 Mbps com tolerância a rajadas de até 512 kB
  • Prata: provê links de 1 Mbps com tolerância a rajadas de até 256 kB
  • Bronze: provê links que aproveitam a capacidade ociosa da rede, porém limitados a 2 Mbps

Além disso, clientes podem contratar capacidade da rede para tráfego sensível a atraso (ex: VoIP).

  1. Implante o serviço Olímpico nessa rede. Ajax contratou um link Ouro, Tabajara contratou Prata, e Lexcorp contratou bronze.
  2. Modifique a rede para que Ajax e Tabajara contratem Ouro, e Lexcorp contrate Bronze
  3. Modifique a rede para que Tabajara contrate também capacidade adicional para até 4 chamadas VoIP simultâneas (assuma uso de PCM-u).
  4. DESAFIO: e se for necessário implementar precedências de descarte para as classes AF ? Por exemplo, dentro da classe AF1 podem existir três precedências de descarte: AF11, AF12 e AF13. A ideia é que, em caso de congestionamento, pacotes marcados com AF13 sejam descartados antes de AF12, e estes sejam descartados antes de AF11. Investigue e demonstre como isso poderia ser feito no Linux (dica: veja a disciplina de filas GRED).

16/02: IntServ: Serviços Integrados na Internet

IntServ: serviços integrados para provimento de QoS fim-a-fim. Nesse modelo, fluxos de pacotes entre um transmissor e um receptor têm seus requisitos de QoS atendidos pela infraestrutura de rede. Para isso, são efetuadas reservas de recursos (largura de banda, priorização) em todos os roteadores ao longo do caminho entre transmissor e um receptor.


IntServ é introduzido pela RFC 1633.


Intserv1.jpeg


Elementos da arquitetura IntServ:

  • Especificação de fluxo: define as características de um fluxo e os recursos que ele precisa da rede:
    • TSpec (Traffic Specification): especificação de características de um fluxo (gerada pelo transmissor): TokenBucketRate, TokeBucketSize, PeakRate, MinimumPolicedUnit, MaximumPacketSize
    • RSpec (Reservation Specification): especificação de características de uma reserva de recursos (gerada pelo receptor). Contém os mesmos parâmetros que TSpec, além de uma classe de serviço (garantida, carga controlada ou melhor-esforço) e um filtro que descreve o fluxo (endereços IP dos pares, ports TCP ou UDP).
  • RSVP (Resource Reservation Protocol): protocolo de sinalização para negociar reservas de recursos ao longo do caminho a ser usado pelo fluxo.


Intserv-model.jpg


A sinalização RSVP ocorre em duas etapas:

  1. O transmissor do fluxo envia mensagens PATH para o receptor. Essas mensagens contém a descrição do fluxo (TSpec).
  2. Se aceitar a especificação de fluxo contida na mensagem PATH, o receptor responde com uma mensagem RESV. Essa mensagem especifica a reserva a ser feita ao longo do caminho entre transmissor e receptor (i.e. contém um RSpec) . Cada roteador ao longo do caminho testa se a reserva pode ser satisfeita, e em caso afirmativo propaga a mensagem RESV ao próximo roteador.

Obs: o pedido de reserva feito pelo transmissor (mensagens PATH) deve ocorrer periodicamente. Caso os roteadores ou o receptor fiquem um certo tempo sem receber uma mensagem PATH, as reservas correspondentes são canceladas.
Obs 2: fluxos são unidirecionais, portanto as reservas são feitas também de forma unidirecional.

Rsvp-signaling.jpg


Segundo um artigo da Cisco, IntServ possui como pontos fortes:

  • Um tipo de serviço garantido que limita o atraso fim-a-fim e proporciona uma largura de banda para o tráfego que se adequade às especificações da reserva de recursos.
  • Um tipo de serviço de carga controlada, o qual provê um desempenho superior a melhor esforço, além de um atraso fim-a-fim baixo sob cargas leves ou moderadas na rede.
  • Possibilidade de proporcionar a qualidade de serviço pedida para cada fluxo na rede, contanto que tenha sido sinalizado usando RSVP e existam recursos disponíveis.


... mas tem também pontos fracos:

  • Cada equipamento ao longo do caminho de um pacote, incluindo os sistemas finais (ex: PCs e servidores), precisam entender e usar RSVP e serem capazes de sinalizar a QoS pedida.
  • Reservas de recursos em cada equipamento ao longo do caminho são "brandas", o que significa que precisam ser renovadas periodicamente. Com isso, há um tráfego de sinalização adicional que contribui para o aumento da carga na rede, o qual aumenta a chance de que a reserva expire se os pacotes de renovação forem perdidos.
  • A manutenção de estados sobre as reservas de recursos em cada roteador, combinada com controle de admissão e uma maior quantidade de memória necessária para suportar um grande número de reservas, aumenta a complexidade de cada nó da rede ao longo do caminho.
  • Como informação sobre estados para cada reserva precisa ser mantida em todos os roteadores ao longo do caminho, torna-se um desafio manter centenas de milhares de fluxos que passem pelo núcleo da rede.

A seguinte explicação (obtida aqui) aponta outras limitações do Intserv, e comenta sobre sua adoção em redes corporativas e de provedores: 


Although IntServ is a straightforward QoS model, end-to-end service guarantees cannot be supported unless all 
nodes along the route support IntServ. This is obviously so because any best-effort node along any route can 
treat packets in such a way that the end-to-end service agreements are violated. In the case of end-end 
implementation of IntServ QoS model, it is recognized by the industry that the support of per-flow guarantees 
in the core of the Internet will pose severe scalability problems. Therefore, scalability is a key 
architectural concern for IntServ, since it requires end-to-end signaling and must maintain a per-flow 
soft state at every router along the path. Other concerns are, how to authorize and prioritize 
reservation requests, and what happens when signaling is not deployed end-to-end. Because of 
these issues, it is generally accepted that IntServ is a better candidate for enterprise 
networks (i.e., for access networks), where user flows can be managed at the desktop user level, 
than for large service provider backbones. A hybrid model (RSVP-DS) that uses RSVP at the edges 
and DiffServ in the backbone has been proposed and seems to be winning consensus as a backbone 
service architecture concept.

19/02: Serviços Integrados na Internet

Atividade

Para visualizar o efeito de usar IntServ, iremos utilizar o simulador Opnet.

  1. Execute o simulador e abra o modelo RSVP.
    1. Leia a descrição do modelo, que explica o que ele pretende mostrar.
    2. No menu Scenarios->Switch scenario selecione configuration. Em seguida, execute o modelo.
    3. Selecione o menu Results-Compare results para visualizar os resultados, observando os atrasos fim-a-fim nos sistemas finais e nos roteadores.
    4. Veja os atributos relativos ao RSVP nos sistemas finais e nos roteadores. Veja também no perfil da aplicação (abra o pop-up menu de Application Definition e selecione Edit Attributes->Application Definitions->VoIP RSVP used->Description). Além disso, observe as especificações de fluxos RSVP contidas em Qos Attribute Config: abra o pop-up menu, selecione Edit Attributes e visualize RSVP Flow Specification->row 0.
  2. O que acontece se for modificada a especificação de fluxo RSVP ? Experimente aumentar a largura de banda (TokenBucketRate) ou tolerância a rajada (TokenBucketSize). Isso pode ser feito em Qos Attribute Config: abra o pop-up menu, selecione Edit Attributes e visualize RSVP Flow Specification->row 0.
    1. Execute o modelo com a nova especificação de fluxo.
    2. Visualize os resultados. O que mudou em relação à primeira execução ?
  3. Qual o efeito de haver um roteador sem suporte a RSVP no meio do caminho ?
    1. Duplique o cenário, salvando-o com o nome RSVP 2.
    2. Adicione um roteador entre Router 1 e Router 2. Conecte-o a esses outros roteadores com links PP DS0.
    3. Refaça a simulação, e observe os resultados. O que mudou em relação ao atraso fim-a-fim ?
  4. Ainda sobre o roteador sem RSVP que foi adicionado, faça a seguinte modificação:
    1. Conecte o computador client_no_RSVP ao novo roteador (e desconecte-o de Router 1). Use um link PP DS0'.
    2. Execute a simulação.
    3. Visualize os resultados. O que mudou em relação à simulação anterior (e em relação à primeira simulação) ? Observe especialmente o atraso fim-a-fim.


Rsvp-model-2.png
O modelo RSVP com mais um roteador.


TAREFA: Leitura da semana

  • Para apresentar nesta 5a feira (21/02)

Leia este artigo da Cisco sobre engenharia de tráfego em redes MPLS. Em particular, estude a seção que trata de RSVP-TE, uma versão do protocolo RSVP adaptada para o uso em MPLS.

21/02: Firewall

Uma introdução ao iptables

O filtro IP do Linux se chama NetFilter, e suas regras são configuradas por meio do utilitário iptables (ver também seu manual). Com iptables se podem adicionar ou remover regras do Netfilter, além de consultar estatísticas sobre essas regras (ex: contadores dos pacotes e bytes que selecionaram cada regra). As regras são agrupadas em conjuntos denominados chains ("cadeias"), as quais estão relacionadas com o contexto que cada pacote está sendo analisado. Existem três chains predefinidas:

  • INPUT: contém as regras a serem aplicadas aos pacotes destinados ao próprio firewall.
  • OUTPUT: contém as regras a serem aplicadas aos pacotes transmitidos pelo próprio firewall.
  • FORWARD: contém as regras a serem aplicadas aos pacotes em trânsito pelo firewall (isto é, pacotes recebidos de uma interface e sendo encaminhados através de outra interface).

Assim, usando-se o iptables podem ser adicionadas regras a cada uma dessas chains, dependendo do policiamento de tráfego a ser implantado no firewall.


Iptables-chains.png


Uma regra deve especificar basicamente três coisas:

  • Chain: em que chain deve ser adicionada.
  • Seletor: informações a serem usadas para selecionar os pacotes a que ela deve ser aplicada.
  • Alvo (target): ação a ser executada sobre o pacote que ativar a regra.

Por exemplo, a regra abaixo permite o encaminhamento de todos os segmentos TCP destinados a porta 80:


Iptables-intro.png


Desta forma, a escrita das regras depende de conhecer as opções para definição de seletores, e os possíveis alvos. Algumas opções de uso comum para composição de seletores são listadas abaixo, sendo que o que está entre colchetes ([]) é opcional. Um seletor pode ser composto por uma combinação dessas opções. Para mais detalhes leia o manual.

Opção Descrição Exemplo
-s IP[/Mascara] endereço IP de origem -s 200.135.37.64/26
-d IP[/Mascara] endereço IP de destino -d 8.8.8.8
-p Protocolo protocolo de transporte (tcp ou udp) -p tcp
--dport numero Port de destino --dport 80
--sport numero Port de origem --sport 53
--syn Se flag SYN está acesa (somente TCP)
--tcp-flags Flags1 Flags2 Se somente as flags listadas em Flags1 estão acesas dentre as Flags2 --tcp-flags SYN,ACK,RST,FIN SYN
-i interface Se pacote foi recebido pela interface -i eth0
-o interface Se pacote vai sair pela interface -o eth1
-m state --state ESTADO Identifica o estado do fluxo, o qual pode ser:
NEW: início de um fluxo
ESTABLISHED: parte de um fluxo estabelecido
RELATED: inicia um novo fluxo, porém relacionado com um fluxo existente		 -m state --state NEW,RELATED


Os alvos definem o que fazer com um pacote selecionado por uma regra. As ações possíveis estão listadas abaixo:


Alvo Descrição Exemplo
ACCEPT aceita o pacote -j ACCEPT
DROP descarta o pacocte -j DROP
REJECT rejeita o pacote, devolvendo um código de erro ICMP para seu remetente -j REJECT
LOG registra o pacote no log do sistema -j LOG
uma_chain passa o pacote para ser processado pela chain uma_chain -j rede_interna


Salvando e restaurando regras do iptables

Uma vez obtido um conjunto de regras que funcione como desejado, deve-se poder salvá-lo para que possa ser reativado sempre que desejado (ex: no boot). Existem dois utilitários que auxiliam nessa tarefa, sendo eles:

  • iptables-save: escreve as regras atuais na saída padrão, que normalmente é redirecionada para um arquivo: 
    iptables-save > minhas_regras
  • iptables-restore: instala as regras lidas da entrada padrão, normalmente redirecionada de um arquivo: 
    iptables-restore < minhas_regras

Atividade

Cada aluno deve implantar a seguinte rede virtual em seu computador:


Lab-firewall-intro.png


O firewall e o Pc devem ser máquinas virtuais. Você pode usar o Virtualbox ou o Netkit. Se optar pelo segundo, use a seguinte configuração de rede (grave-a em um arquivo chamado Lab.conf): 

# Obs: substitua X pelo número do seu computador
pc[type]=generic
firewall[type]=gateway
#internet[type]=generic

pc[eth0]=link:ip=10.1.X.1/24
firewall[eth1]=link:ip=10.1.X.254/24
firewall[eth0]=uplink:bridge=eth0:ip=192.168.2.100+X/24
#firewall[eth0]=externo:ip=192.168.2.100+X/24
#internet[eth0]=externo:ip=192.168.2.1/24

pc[default_gateway]=10.1.X.254
firewall[default_gateway]=192.168.2.1
#internet[default_gateway]=192.168.2.100+x/24

No caso do Netkit, execute o programa gnome-netkit para executar a rede virtual. Selecione o menu File->Load and run e carregue o arquivo Lab.conf.

Se for usado o Virtualbox, use a máquina virtual Rmu-server para ser o firewall, e Rmu-cliente para ser o Pc. Inicie-as, certificando-se de que suas interfaces de rede estejam em modo bridge. Configure os endereços IP de suas interfaces e também suas rotas default.

DICA

É útil ativar o NAT na interface externa do firewall (eth0 na nossa rede de teste): 

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Cenário 1: Uma rede pequena sem servidores

Em uma rede pequena e que não oferece serviços, todos os fluxos se originam internamente. Assim, o firewall deve impor que somente fluxos internos possam passar. Com base nisso, configure seu firewall das seguintes formas:

  1. Caso 1: os computadores internos podem acessar qualquer serviço externo.
    • Com filtro stateless: 
      # As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall

# Por default, bloqueia tudo
iptables -P FORWARD DROP

# Libera todos pacotes TCP que entrarem pela interface eth1
iptables -A FORWARD -i eth1 -p tcp -j ACCEPT

# Libera pacotes UDP destinados a porta 53 (DNS), contanto que tenham entrado pela interface eth1
iptables -A FORWARD -i eth1 -p udp --dport 53 -j ACCEPT

# Libera pacotes UDP com port de origem 53 (resposta do DNS), contanto que tenham entrado pela interface eth0
iptables -A FORWARD -i eth0 -p udp --sport 53 -j ACCEPT

# Libera segmentos TCP vindos pela interface eth0 e que tenham as flags SYN e ACK acesas (resposta de pedido de conexão TCP)
iptables -A FORWARD -i eth0 -p tcp --tcp-flags SYN,ACK SYN,ACK -j ACCEPT


# Libera segmentos TCP vindos pela interface eth0 e que não tenham a flags SYN acesa (pertencem a conexões estabelecidas)
iptables -A FORWARD -i eth0 -p tcp ! --syn -j ACCEPT
    • Com filtro stateful: 
      # As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall

# Libera todos pacotes de fluxos estabelecidos
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT

# Libera pacotes que iniciem novos fluxos, originados na rede interna (interface eth1)
iptables -A FORWARD -i eth1 -m state --state NEW -j ACCEPT

# Regra default eh descartar
iptables -P FORWARD DROP
  2. Caso 2: os computadores internos podem acessar somente serviços Web e DNS.
    • Versão alternativa, usando o módulo multiport:
  3. Caso 3: os computadores internos podem acessar qualquer serviço, com exceção de redes eDonkey (ex: emule) e torrent.

26/02: Firewall

Realização dos exercícios da aula de 21/02, mais este aqui:

Atividade

Na rede dos exercícios, inicie uma chamada VoIP entre o PC e o computador do professor (192.168.2.1). Essa chamada deve ser simulada com o siprtp: 

siprtp --ip-addr=10.1.X.1 sip:0@192.168.2.1

Configure seu filtro de pacotes para que essa chamada possa ser realizada a contento.

TAREFA: Leitura da semana

Leiam este texto sobre modelos de firewalls e suas limitações, e preparem-se para apresentá-lo na aula de 05/03. Leiam as seções "Introduction" e "Firewall Limitations" (o restante é propagando de um produto).

28/02: Firewall

... continuação dos exercícios da aula anterior.

05/03: Firewall

  • Projetos de firewalls (ver transparências)


Fluxo de processamento do Netfilter:

Iptables-fluxograma.png


Dicas para NAT

  • Fazendo NAT de todo o tráfego que sai pela interface eth0: 
    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  • Fazendo NAT estático, de forma a associar um determinado IP externo a um IP interno (obs: eth0 é a interface externa): 
    iptables -t nat -A POSTROUTING -o eth0 -s IP_interno -j SNAT --to-source IP_externo
  • Redirecionando um pacote para outro IP e/ou port: 
    iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 2200 -j DNAT --to-destination IP_interno:22

Ativando e desativando as regras do filtro IP (iptables)

O seguinte script, que deve ser salvo com o nome firewall.sh, pode ser usado para ativar e desativar as regras do filtro IP: 

#!/bin/bash
# Variaveis
DEV_LAN=eth0
DEV_WAN=eth1

fw_start(){
  # Adicionando regras
  iptables -A INPUT -i $DEV_LAN -j ACCEPT
}

fw_stop(){
  # Limpando as regras
  iptables -P INPUT ACCEPT
  iptables -t filter -F
  iptables -t nat -F
}

fw_uso(){
  # Mensagem de ajuda
  echo "Sintaxe errada..."
  echo "./$0 (start|stop)"
}

case $1 in
  start)
    fw_start
    ;;
  stop)
    fw_stop
    ;;
  *)
    fw_uso
    ;;
esac
  • Iniciando o firewall: 
    ./firewall.sh start
  • Parando o firewall: 
    ./firewall.sh stop
  • Obtendo informações sobre seu uso: 
    ./firewall.sh

Atividade 1: firewall/roteador para rede doméstica

Uma pequena rede possui um firewall com algumas regras básicas para protegê-la do mundo externo:

  • Política padrão: negar tudo (entrada e roteamento)
  • Usuários da rede local só podem navegar na web, acessar email (POP3, IMAP, SMTP)
  • Firewall pode ser administrado remotamente via SSH, não importando a origem da conexão.
    • Para dificultar ataques por varredura de portas, o servidor SSH deve atender conexões em uma porta diferente da 22.
  • Registrar todas conexões oriundas da rede externa

Atividade 2: serviço SMTP rodando em rede com NAT

Fw-lab3.png


  • Política padrão: negar tudo (entrada e roteamento)
  • Permitir pings a uma taxa máxima de 10 pacotes por minuto
  • Tráfego destinado à porta TCP 25 deve ser encaminhado para a porta 25 do computador M1 (192.168.2.1) da rede local
    • Isso se destina impedir que máquinas da rede local gerem SPAM através de conexões diretas a servidores SMTP externos
  • Tanto o firewall quanto a máquina pc podem ser administradas remotamente via SSH.

Obs: para monitorar quantos pacotes estão casando com as regras: 

watch iptables -t filter -L -v

Obs: para limitar a taxa de pacotes deve-se usar o módulo limit (ver maiores detalhes no manual). Por exemplo: 

# limita as cconexões ao servidor web: no máximo 2 por segundo
iptables -A FORWARD -p tcp -m limit -m multiport -m state -d IP_servidor_web --dports 80,443 
--state NEW --limit-rate 2/second -j ACCEPT
Configuração para Netkit 
# Obs: substitua X pelo número do seu computador
pc[type]=generic
firewall[type]=gateway
 
pc[eth0]=link:ip=10.1.X.1/24
firewall[eth1]=link:ip=10.1.X.254/24
firewall[eth0]=uplink:bridge=eth0:ip=192.168.2.100+X/24
 
pc[default_gateway]=10.1.X.254
firewall[default_gateway]=192.168.2.1
Exemplo de regras 
#!/bin/bash

# Variaveis
DEV_LAN=eth1
DEV_WAN=eth0
 
fw_start(){
  # Adicionando regras
  iptables -P FORWARD DROP

  iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
  iptables -A FORWARD -i $DEV_LAN -p tcp --dport 25 -m state --state NEW -j ACCEPT
  iptables -A FORWARD -i $DEV_LAN -p tcp --dport 80 -m state --state NEW -j ACCEPT
  iptables -A FORWARD -i $DEV_LAN -p tcp --dport 443 -m state --state NEW -j ACCEPT
  iptables -A FORWARD -i $DEV_LAN -p udp --dport 53 -m state --state NEW -j ACCEPT
  iptables -A FORWARD -i $DEV_LAN -p icmp -m state --state NEW -j ACCEPT
  iptables -A FORWARD -i $DEV_WAN -p tcp --dport 22 -d 10.1.1.1 -m state --state NEW -j ACCEPT
  iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

  # NAT
  iptables -t nat -A POSTROUTING -o $DEV_WAN -j MASQUERADE

  # Redirecionamentos ...
  iptables -t nat -A PREROUTING -i $DEV_LAN -p tcp --dport 25 -j DNAT --to-destination 192.168.2.1
  iptables -t nat -A PREROUTING -i $DEV_WAN -p tcp --dport 2200 -j DNAT --to-destination 10.1.1.1:22

}
 
fw_stop(){
  # Limpando as regras
  iptables -P INPUT ACCEPT
  iptables -t filter -F
  iptables -t nat -F
}
 
fw_uso(){
  # Mensagem de ajuda
  echo "Sintaxe errada..."
  echo "./$0 (start|stop)"
}
 
case $1 in
  start)
    fw_start
    ;;
  stop)
    fw_stop
    ;;
  *)
    fw_uso
    ;;
esac

TAREFA: Leitura da semana

Leiam este texto sobre firewalls de nova geração, e se preparem para apresentá-lo na aula de 12/03. Leiam as seções 1 a 4 (se quiserem ler todo o resto, fiquem à vontade ;-).

07/03: Lista de exercícios: Firewall

Nesta aula a turma se organizará em grupos, que devem resolver o seguinte problema:

Fw-lista1.png


A rede acima é composta de dois segmentos, ambos implantados com subredes IP com endereços não roteáveis:

  • DMZ: contém servidores que podem sere acessados a partir da rede externa.
  • Rede interna: contém computadores que não podem ser acessados de fora.

Crie as regras do filtro IP no firewall para que os serviços indicados nos servidores da DMZ possam ser acessados de fora. Essas regras devem também permitir o acesso irrestrito dos computadores da rede interna à Internet (ex: o Pc). Os servidores da DMZ, por sua vez, não podem iniciar conexões - seja para a rede interna ou externa. Além disso, o firewall deve poder ser administrado remotamente via SSH. Por fim, devem ser registrados todos os inícios de conexões e todos os pacotes recusados.

Obs: quem quiser fazer o exercício com o Netkit pode usar o seguinte modelo para a rede: 

global[compact]=1
dmz1[type]=generic
dmz2[type]=generic
pc[type]=generic
firewall[type]=gateway
 
# Um computador pode ser usado para representar a Internet (!?!)
internet[type]=generic
 
dmz1[eth0]=dmz:ip=10.0.0.1/24
dmz2[eth0]=dmz:ip=10.0.0.2/24
firewall[eth1]=dmz:ip=10.0.0.254/24
 
pc[eth0]=lan-interna:ip=192.168.0.1/24
firewall[eth2]=lan-interna:ip=192.168.0.254/24
 
firewall[eth0]=link-internet:ip=172.18.0.100/16
 
# A "Internet" tem só o IP 172.18.0.1 ;-)
internet[eth0]=link-internet:ip=172.18.0.1/16
 
dmz1[default_gateway]=10.0.0.254
dmz2[default_gateway]=10.0.0.254
 
pc[default_gateway]=192.168.0.254

# Se o script firewall.sh ficar em /root, ele pode ser preservado para poder ser usado 
# em proximas execucoes da rede virtual. Porém para isso deve-se exportar 
firewall[preserve]=/root/firewall.sh

Estendendo as regras do firewall

Na rede do exercício sobre firewall, algumas novas regras de policiamento de tráfego devem ser implantadas:

  • DMZ:
    • O servidor SMTP deve poder enviar mensagens para fora.
    • O servidor WWW pode ser acessado via FTP. As portas a serem usadas no modo passivo vão de 30000 a 30200.
  • Rede interna:
    • Acesso a web deve ser feito obrigatoriamente por meio de um proxy que roda no firewall. Esse proxy atende na porta TCP 3128.
    • Envio de email somente pode ser feito por meio do servidor SMTP que está na DMZ.
    • Programas de chat devem ser bloqueados (ex: MSN, Jabber, Skype).


12/03: Projeto final

O projeto final de RMU trata da implantação de uma rede corporativa composta por uma matriz e uma filial. Ambas unidades da empresa possuem suas próprias redes, que possuem um link para uma operadora de longa distância. A empresa usa essa infraestrutura de rede para aplicações corporativas entre matriz e filial (incluindo ERP e VoIP), e para acesso a Internet.

A turma deve se dividir em 04 equipes. Cada equipe deve implantar sua rede corporativa de forma a atender estes requisitos:

  • Serviço telefônico dentro da empresa deve ser feito com VoIP:
  • Os diferentes tipos de tráfego devem ter seus requisitos de QoS atendidos:
  • As comunicações dos usuários devem ser policiadas:

Proj-2012-2.png

Detalhamento

O trabalho será feito usando o Netkit (versão 1.80 ou superior), pois do contrário seriam necessários dois computadores e pelo menos 5 VM Virtualbox. O Asterisk foi portado para o Netkit, porém somente com canais IAX2 e SIP. Como softphone deve ser usado o siprtp para simular chamadas VoIP.

OBS: Os links PPPoE entre AC e os Firewalls têm taxa de downstream de 1 Mbps, e de upstream de 400 kbps. Isso já está implantado na configuração do experimento.

Requisitos:

  • As redes usam NAT para acessar a Internet.
  • Por default, tudo está bloqueado.
  • Chamadas VoIP têm prioridade a todos demais tipos de tráfego, porém limitadas a até duas chamadas VoIP simultâneas.
  • Tráfego de aplicações corporativas têm prioridade em relação a tráfego com a Internet.
  • Chamadas VoIP podem ser feitas somente entre telefones IP da empresa.
  • Em cada rede da empresa pode haver dois ou mais telefones IP.
  • O servidor intranet pode ser acessado da Internet para serviço Web (protocolos HTTP e HTTPS nas portas padrões).
  • Firewall da matriz pode ser acessado da Internet com SSH.
  • Firewall da filial pode ser acessado com SSH, porém somente a partir do Firewall da matriz.
  • Usuários das redes da empresa podem acessar qualquer serviço da Internet baseado em TCP. Serviços baseados em UDP não são permitidos.
  • Os Firewalls rodam servidores DNS, e assim os usuários das redes da empresa somente podem fazer consultas DNS aos Firewalls.
  • Protocolo ICMP está liberado, porém pings estão limitados a mensagens de 100 bytes e a taxas de até 2 mensagens por segundo.
  • O Gateway + Firewall da rede da esquerda PODE ser também um proxy SIP.
Configuração da rede para o Netkit 
# Rede da Matriz: 
# - rede dos usuarios: 192.168.50.0/24
# - DMZ: 192.168.100.0/24
# Rede da Filial: 192.158.5.0/24
#
# Global attributes: these values are obtained automatically from menu General->Preferences
global[compact]=True
global[mem]=32
#
pbx[type]=pbx
pc1[type]=generic
fone1[type]=generic
pc2[type]=generic
fone2[type]=generic
ac[type]=pppoe
fw1[type]=gateway
fw2[type]=gateway
intranet[type]=generic
internet[type]=generic

# O AC PPPoE, que prove links PPPoE com 1 Mbps de downstream
ac[pppoe]=RMU:interface=eth0:users=(aluno1,senha1),(aluno2,senha2):range=192.168.10.1,192.168.10.10:ip=192.168.10.254:rate=1000
ac[eth0]=adsl
ac[eth1]=link:ip=192.168.1.10/24

# isto simula a internet ;-)
internet[eth0]=link:ip=192.168.1.1/24
internet[route]=192.168.0.0/16:gateway=192.168.1.10

# Os firewalls ... os links PPPoE tem 400kbps de upstream
fw1[eth0]=adsl:mode=pppoe:pppoe_user=aluno1:pppoe_password=senha1:pppoe_ac=RMU:rate=400
fw2[eth0]=adsl:mode=pppoe:pppoe_user=aluno2:pppoe_password=senha2:pppoe_ac=RMU:rate=400

# A rede da filial
fw1[eth1]=filial:ip=192.168.5.254/24
fw1[preserve]=/root/firewall.sh
pc1[eth0]=filial:ip=192.168.5.1/24
fone1[eth0]=filial:ip=192.168.5.2/24
pc1[default_gateway]=192.168.5.254
fone1[default_gateway]=192.168.5.254

# A rede da matriz
fw2[eth1]=matriz:ip=192.168.50.254/24
fw2[eth2]=dmz:ip=192.168.100.254/24
fw2[preserve]=/root/firewall.sh
pc2[eth0]=matriz:ip=192.168.50.1/24
fone2[eth0]=matriz:ip=192.168.50.2/24
intranet[eth0]=dmz:ip=192.168.100.2/24
pc2[default_gateway]=192.168.50.254
fone2[default_gateway]=192.168.50.254
intranet[default_gateway]=192.168.100.254
intranet[services]=apache2:ssh

# O PBX Asterisk
pbx[eth0]=dmz:ip=192.168.100.1/24
pbx[default_gateway]=192.168.100.254
pbx[preserve]=/usr/local/asterisk/etc


Data de entrega: até 21/03/2013

14/03: Apresentação de TCC 1

Todos convidados ...

20/03: Avaliação 3

  • Disciplinas de filas
  • Modelos de QoS para Internet (Diffserv e Intserv)
  • Firewalls

21/03: Apresentação do projeto

No laboratório ...

22/03: Recuperação

Disponível em “https://wiki.sj.ifsc.edu.br/index.php?title=RMU-2012-2&oldid=94791”