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

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
 
(110 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 29: Linha 29:
 
  !1a prova
 
  !1a prova
 
  !2a prova
 
  !2a prova
 +
!Trabalho Servidor de video
 
  !Trabalho VoIP
 
  !Trabalho VoIP
 
  !Trabalho Firewalls
 
  !Trabalho Firewalls
 
  !FINAL
 
  !FINAL
 +
|-
 +
|Aliny ||D+/C ||C ||A ||B<br>ura inacessível || C||C
 +
|-
 +
|Francisco ||C+ ||B+ ||A || B<br>numeração dos contatos<br>pbxa não permite chamar contatos locais|| A|| B
 +
|-
 +
|Leandro ||C+ ||C+ ||A || B<br>numeração dos contatos<br>pbxa não permite chamar contatos locais|| C||C
 +
|-
 +
|Liamari ||D/D ||D/D || ||D<br>alguns telefones não registram<br>pbxa desvia chamadas para ura<br>pbxa não encaminha para outros pbx || D||D
 +
|-
 +
|Maicky ||D+/C ||C ||A ||B<br>numeração dos contatos<br>pbxa não permite chamar contatos locais ||C ||C
 +
|-
 +
|Maycon ||B ||C+ ||A ||A || A||A
 +
|-
 +
|Nicole ||C ||C ||A ||A || A||C
 
  |}
 
  |}
  
Linha 334: Linha 349:
 
* [http://blog.plumi.org/ Plumi]
 
* [http://blog.plumi.org/ Plumi]
 
* [http://www.clip-bucket.com/ Clip-bucket]
 
* [http://www.clip-bucket.com/ Clip-bucket]
 +
* [http://cumulusclips.org/ Cumulus]
 +
* [http://mediadrop.net/ MediaDrop]
 +
* [http://popcorn-time.se/ Popcorn Time]
  
  
Linha 344: Linha 362:
 
|Equipe 1 ||Nicole, Francisco || equipe1.rmu.sj.ifsc.edu.br || http://equipe1.rmu.sj.ifsc.edu.br/
 
|Equipe 1 ||Nicole, Francisco || equipe1.rmu.sj.ifsc.edu.br || http://equipe1.rmu.sj.ifsc.edu.br/
 
|-
 
|-
−
|Equipe 2 || || equipe2.rmu.sj.ifsc.edu.br || http://equipe2.rmu.sj.ifsc.edu.br/
+
|Equipe 2 ||Leandro,Maicky || equipe2.rmu.sj.ifsc.edu.br || http://equipe2.rmu.sj.ifsc.edu.br/
 
|-
 
|-
−
|Equipe 3 || || equipe3.rmu.sj.ifsc.edu.br || http://equipe3.rmu.sj.ifsc.edu.br/
+
|Equipe 3 || Maycon,Aliny|| equipe3.rmu.sj.ifsc.edu.br || http://equipe3.rmu.sj.ifsc.edu.br/
 +
|-
 +
|Equipe 4 ||Liamari || equipe4.rmu.sj.ifsc.edu.br || http://equipe4.rmu.sj.ifsc.edu.br/
 
|}
 
|}
  
Linha 460: Linha 480:
 
Concluir (ou iniciar) o sistema de distribuição de video do Projeto 1.
 
Concluir (ou iniciar) o sistema de distribuição de video do Projeto 1.
  
−
= 31/08: Introdução a Voz sobre IP (VoIP) =
+
= 30/08: Introdução a Voz sobre IP (VoIP) =
  
 
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-22.pdf Transparências]
 
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-22.pdf Transparências]
Linha 967: Linha 987:
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
 
[general]
 
[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
 
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 
  passo),
 
  passo),
Linha 981: Linha 999:
  
 
[alunos](!)
 
[alunos](!)
 +
type=friend ; pode efetuar e receber chamadas
 +
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
 
context=alunos
 
context=alunos
  
 
[professores](!)
 
[professores](!)
 +
type=friend ; pode efetuar e receber chamadas
 +
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
 
context=professores
 
context=professores
  
 
[coordenacao](!)
 
[coordenacao](!)
 +
type=friend ; pode efetuar e receber chamadas
 +
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
 
context=coordenacao
 
context=coordenacao
 
   
 
   
Linha 1 017: Linha 1 041:
 
[alunos]; contexto alunos
 
[alunos]; contexto alunos
 
; extensoes dos alunos
 
; extensoes dos alunos
 +
exten=>100,1,Dial(SIP/100)
 +
same=>n,Hangup
 +
exten=>101,1,Dial(SIP/101)
 +
same=>n,Hangup
  
 
[professores]; contexto professores
 
[professores]; contexto professores
 
; extensoes dos professores
 
; extensoes dos professores
 +
exten=>200,1,Dial(SIP/200)
 +
same=>n,Hangup
 +
exten=>201,1,Dial(SIP/201)
 +
same=>n,Hangup
  
 
[coordenacao]; contexto coordenacao
 
[coordenacao]; contexto coordenacao
 
; extensoes da coordenacao
 
; extensoes da coordenacao
−
 
+
exten=>300,1,Dial(SIP/300)
 +
same=>n,Hangup
 +
exten=>301,1,Dial(SIP/301)
 +
same=>n,Hangup
 +
include=>alunos
 +
include=>professores
 
</syntaxhighlight>
 
</syntaxhighlight>
 
{{collapse bottom}}
 
{{collapse bottom}}
Linha 1 040: Linha 1 077:
  
 
'''Questões:'''
 
'''Questões:'''
−
# Que papel desempenhou o Asterisk para os softphones ? UAC, UAC ou algo diferente ?
+
# Que papel desempenhou o Asterisk para os softphones ? UAS, UAC ou algo diferente ?
 
# Entre que agentes ocorreram os diálogos identificados ?
 
# Entre que agentes ocorreram os diálogos identificados ?
 
# A stream de audio seguiu o mesmo caminho que a sinalização SIP ?
 
# A stream de audio seguiu o mesmo caminho que a sinalização SIP ?
Linha 1 114: Linha 1 151:
 
O plano de discagem acima possibilita chamar qualquer número entre 100 e 199.
 
O plano de discagem acima possibilita chamar qualquer número entre 100 e 199.
  
−
== Protocolo RTP ==
+
== Asterisk e PSTN ==
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-22.pdf Transparências]
+
Um PBX IP como o Asterisk pode realizar chamadas tanto pela rede telefônica convencional (PSTN) quanto pela rede de dados com VoIP. Para isso, são necessárias interfaces de hardware para os diferentes tipos de canais existentes usados na PSTN. Um exemplo simplificado de uma rede telefônica com telefones IP e convencionais pode ser vista abaixo.
−
* [http://www.cs.columbia.edu/~hgs/rtp/faq.html Uma FAQ sobre RTP (muito boa)]
 
−
* [http://tools.ietf.org/html/rfc3550 RFC 3550: RTP: A Transport Protocol for Real-Time Applications]
 
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/voip/rtp.pdf Capítulo 11 do livro ''SIP: Understanding the Session Initiation Protocol, 3rd ed'']
 
−
* Cap. 7 do livro ''Redes de Computadores e a Internet, 5a edição'', de James Kurose.
 
  
 +
[[imagem:Asterisk-khomp1.png]]
 +
<br>''Cenário com telefones IP e convencionais''
  
−
O protocolo RTP (''Real-Time Protocol'') foi desenvolvido para possibilitar o transporte de datagramas de tempo-real contendo voz, video, ou outro tipo de dados, sobre IP. Tanto H.323 quanto o modelo SIP usam RTP para o transporte de media, tornando-o o padrão mais comum para comunicações desse tipo na Internet. Apesar desse protocolo não prover qualidade de serviço (i.e. ele não possui mecanismos para atender tais tipos de requisitos), ele torna possível a detecção de alguns dos problemas introduzidos por uma rede IP, tais como:
 
−
* ''Perda de pacotes ''
 
−
* ''Atraso fim-a-fim variável''
 
−
* ''Chegada de pacotes fora de ordem''
 
−
 
  
−
Esses problemas não são novidade ... nós já os discutimos nas aulas sobre [[RMU-2013-1#Transmiss.C3.A3o_de_dados_multimidia|transmissão de dados multimidia]]. O que há de novo é um '''protocolo que dá subsídios para as técnicas que buscam atender requisitos de qualidade de serviço'''. Esses subsídios são informações providas pelo RTP para ajudar a identificar os problemas citados acima, as quais são:
+
A rede acima 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, e assim consegue 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. Porém, como já comentado, a integração entre as duas redes depende, além do PBX IP, de hardware específico.
−
* ''Identificação do tipo do conteúdo que está sendo carregado (codec)'': isso informa ao receptor como ele deve decodificar o conteúdo transportado (ver esta [http://en.wikipedia.org/wiki/RTP_audio_video_profile tabela de identificadores de codec usados pelo RTP])
+
 
−
* ''Numeração de sequência'': essa informação possibilita identificar pacotes perdidos ou fora de ordem.
+
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:
−
* ''Marcação de tempo (timestamp)'': com isso é possível efetuar o cálculo de variação de atraso e implementar algum mecanismo de  sincronização com a fonte (ex: atraso de reprodução).
+
* [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.
  
 +
No laboratório de Redes 2 existem módulos com esses tipos de interfaces, os quais foram projetados especialmente para serem usados com PBX IP (Asterisk, FreeSwitch e possivelmente outros). Esses módulos se apresentam como ''placas externas'', o que significa que funcionam como se fossem placas de entrada e saída instaladas dentro do computador onde roda o PBX IP. Por causa dessa característica, seu fabricante (Khomp) denominou-os [http://www.khomp.com.br/v2/?opcao=avulsa&id=15 EBS (External Board Series)]. O modelo existente no laboratório é o [http://www.khomp.com.br/v2/?opcao=ver_produto&id_c=8&id_p=68 EBS Modular], que combina diferentes interfaces em um mesmo módulo. Com esses módulos será possível implantar a rede telefônica privativa mostrada acima.
  
−
Essas informações fazem parte da PDU RTP, como se pode ver a seguir:
+
= 11/09: Interligando PBX Asterisk por meio de troncos SIP ou IAX2  =
  
−
{| border="1" cellpadding="2"
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-25.pdf Transparências]
−
!Localização do RTP na camada de transporte
 
−
!Cabeçalho RTP
 
−
|-
 
−
|[[imagem:Rtp1.png|200px]] ||[[imagem:Rtp-header.png]]
 
−
|}
 
  
−
=== RTCP ===
+
<!-- == Interligando PBX Asterisk ==
  
−
Além do RTP, o protocolo auxiliar RTCP (''Real-Time Control Protocol'', também definido na [http://tools.ietf.org/html/rfc3550 RFC 3550]) foi definido para o '''monitoramento da entrega dos pacotes''' (recepção da stream). Com esse protocolo, os participantes de uma sessão de media podem fazer o intercâmbio de relatórios e estatísticas. Cada tipo de relatório é transportado por um tipo de pacote RTCP. O uso de relatórios possibilita o ''feedback'' sobre a qualidade da comunicação, incluindo informações como:
+
Neste novo cenário, os PBX Asterisk serão interligados por meio de troncos analógicos (FXS-FXO) ou digitais (E1).
−
* Número de pacotes enviados e recebidos
 
−
* Número de pacotes perdidos
 
−
* ''Jitter'' (variação de atraso)
 
  
−
Os cinco tipos de relatórios são:
+
[[imagem:Asterisk-khomp2.png]]
−
* Relatório do transmissor (''Sender Report - SR'')
+
<br>''Dois PBX interligados por um tronco analógico''
−
* Relatório do receptor (''Receiver Report - RR'')
 
−
* Descrição da fonte (''Source Description - SDES'')
 
−
* ''Bye''
 
−
* Específico da aplicação (''Application Specific - APP'')
 
  
−
Como o tráfego RTCP é puramente overhead, o protocolo foi projetado para que seu consumo da capacidade da rede seja constante, não importa quantos participantes da sessão de media existam. A ideia é que quanto mais participantes houver, menos frequentemente os relatórios RTCP são enviados. Por exemplo, se em uma conferência houver somente dois participantes, os relatórios podem ser enviados a cada 5 segundos. Se houver quatro participantes, os relatórios são enviados a cada 10 segundos. Com isso o consumo de banda para relatórios se mantém constante e previsível.
+
Apesar de parecer mais complexo, este novo cenário é bastante parecido com o da [[RMU-2013-1#17.2F04:_VoIP_e_Asterisk_.28continua.C3.A7.C3.A3o.29|aula passada]]. A diferença básica entre eles está no plano de discagem, que deve encaminhar e receber chamadas vindas do tronco analógico.
  
 
=== Atividade ===
 
=== Atividade ===
  
−
Essa atividade busca ilustrar os fluxos RTP com um exemplo:
+
Implante a rede formada pelos dois PBX interligados por um tronco analógico, e escreva o plano de discagem para que chamadas possam ser feitas entre os telefones vinculados a um ou outro PBX. Assuma que os telefones do PBX superior tenham numeração ''2XXX'', e os do PBX inferior usem numeração ''4XXX''.
−
# Estabeleça uma chamada VoIP entre dois softphones usando o Asterisk como intermediário.
+
-->
−
# Execute o wireshark no computador onde roda o Asterisk, 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.
+
A interligação entre PBX Asterisk pode ser feita via rede de dados usando os protocolos SIP ou IAX2. No primeiro caso, o encaminhamento de uma chamada entre dois PBX funciona como uma chamada SIP usual, e isso significa que a sinalização é feita com SIP e a media flui em separado com RTP. No segundo caso, o protocolo [http://en.wikipedia.org/wiki/Inter-Asterisk_eXchange IAX2 (''Inter-Asterisk eXchange'')] encapsula tanto a sinalização quanto os fluxos de media, o que simplifica o estabelecimento do tronco.
−
# Estime o jitter durante a recepção de ao menos 15 segundos de audio.
 
−
# Observe os relatórios RTCP:
 
−
#* Que tipos de relatórios são enviados ?
 
−
#* Com que frequência esses relatórios são transmitidos ?
 
−
#* Que informações esses relatórios contêm ?
 
  
−
== Asterisk e PSTN ==
+
[[imagem:Modelo-pbx-asterisk.png|520px]]
  
−
Um PBX IP como o Asterisk pode realizar chamadas tanto pela rede telefônica convencional (PSTN) quanto pela rede de dados com VoIP. Para isso, são necessárias interfaces de hardware para os diferentes tipos de canais existentes usados na PSTN. Um exemplo simplificado de uma rede telefônica com telefones IP e convencionais pode ser vista abaixo.
 
  
−
[[imagem:Asterisk-khomp1.png]]
+
Inicialmente criaremos a infraestrutura para chamadas VoIP, a qual aumentaremos gradualmente para podermos reproduzir o modelo aqui descrito.
−
<br>''Cenário com telefones IP e convencionais''
 
  
 +
== Tronco SIP ==
  
−
A rede acima 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, e assim consegue 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. Porém, como já comentado, a integração entre as duas redes depende, além do PBX IP, de hardware específico.
+
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.
  
−
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:
+
[[imagem:Sip-trunk.png]]
−
* [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.
 
  
−
No laboratório de Redes 2 existem módulos com esses tipos de interfaces, os quais foram projetados especialmente para serem usados com PBX IP (Asterisk, FreeSwitch e possivelmente outros). Esses módulos se apresentam como ''placas externas'', o que significa que funcionam como se fossem placas de entrada e saída instaladas dentro do computador onde roda o PBX IP. Por causa dessa característica, seu fabricante (Khomp) denominou-os [http://www.khomp.com.br/v2/?opcao=avulsa&id=15 EBS (External Board Series)]. O modelo existente no laboratório é o [http://www.khomp.com.br/v2/?opcao=ver_produto&id_c=8&id_p=68 EBS Modular], que combina diferentes interfaces em um mesmo módulo. Com esses módulos será possível implantar a rede telefônica privativa mostrada acima.
+
A ativação de um entroncamento SIP entre dois PBX Asterisk pode ser feita seguindo o exemplo abaixo:
  
−
= 11/09: VoIP e Asterisk (continuação) =
+
{| border="1" cellpadding="2"
 +
!PBX
 +
!sip.conf
 +
!extensions.conf
 +
|-
 +
|'''Norte''' || <syntaxhighlight lang=text>[Sul]
 +
type=user
 +
secret=supersecreta
 +
host=IP_PBX_Norte
 +
disallow=all
 +
allow=ulaw
 +
;canreinvite=no
 +
directmedia=no
 +
context=troncoSIP
 +
qualify=yes
  
−
= 13/09: Interligando PBX Asterisk por meio de troncos SIP ou IAX2 =
+
[ParaSul]
−
 
+
type=peer
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-25.pdf Transparências]
+
fromuser=Norte
 +
username=Norte
 +
secret=supersecreta
 +
host=IP_PBX_Sul
 +
disallow=all
 +
allow=ulaw
 +
;canreinvite=no
 +
directmedia=no
 +
qualify=yes</syntaxhighlight>||<syntaxhighlight lang=text> [troncoSIP]
 +
; Ligando para a outra central e, na sequência, o "ramal" de destino
 +
  exten => _4XXX.,1,Dial(SIP/ParaSul/${EXTEN})
 +
same=>n,Hangup</syntaxhighlight>
 +
|-
 +
|'''Sul'''||<syntaxhighlight lang=text>[Norte]
 +
type=user
 +
secret=supersecreta
 +
host=IP_PBX_Sul
 +
disallow=all
 +
allow=ulaw
 +
;canreinvite=no
 +
directmedia=no
 +
context=troncoSIP
 +
qualify=yes
  
−
<!-- == Interligando PBX Asterisk ==
+
[ParaNorte]
−
 
+
type=peer
−
Neste novo cenário, os PBX Asterisk serão interligados por meio de troncos analógicos (FXS-FXO) ou digitais (E1).
+
fromuser=Sul
−
 
+
username=Sul
−
[[imagem:Asterisk-khomp2.png]]
+
secret=supersecreta
−
<br>''Dois PBX interligados por um tronco analógico''
+
host=IP_PBX_Norte
−
 
+
disallow=all
−
Apesar de parecer mais complexo, este novo cenário é bastante parecido com o da [[RMU-2013-1#17.2F04:_VoIP_e_Asterisk_.28continua.C3.A7.C3.A3o.29|aula passada]]. A diferença básica entre eles está no plano de discagem, que deve encaminhar e receber chamadas vindas do tronco analógico.
+
allow=ulaw
 +
;canreinvite=no
 +
directmedia=yes
 +
qualify=yes
 +
</syntaxhighlight>||<syntaxhighlight lang=text> [troncoSIP]
 +
;
 +
; Ligando para a outra central e, na sequência, o "ramal" de destino
 +
exten => _2XXX.,1,Dial(SIP/ParaNorte/${EXTEN})
 +
same=>n,Hangup
 +
</syntaxhighlight>
 +
|}
  
−
=== Atividade ===
+
== 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.
  
−
Implante a rede formada pelos dois PBX interligados por um tronco analógico, e escreva o plano de discagem para que chamadas possam ser feitas entre os telefones vinculados a um ou outro PBX. Assuma que os telefones do PBX superior tenham numeração ''2XXX'', e os do PBX inferior usem numeração ''4XXX''.
+
=== Como fazer esta atividade usando o Netkit ===
−
-->
 
  
−
A interligação entre PBX Asterisk pode ser feita via rede de dados usando os protocolos SIP ou IAX2. No primeiro caso, o encaminhamento de uma chamada entre dois PBX funciona como uma chamada SIP usual, e isso significa que a sinalização é feita com SIP e a media flui em separado com RTP. No segundo caso, o protocolo [http://en.wikipedia.org/wiki/Inter-Asterisk_eXchange IAX2 (''Inter-Asterisk eXchange'')] encapsula tanto a sinalização quanto os fluxos de media, o que simplifica o estabelecimento do tronco.
+
O [[Netkit]] pode ser usado para realizar [[Netkit#PBX_IP_.28Asterisk.29|experimentos com Asterisk e chamadas SIP]]. Ele contém o Asterisk, e também dois softwares para teste de chamadas - pjsua e siprtp. Esses recursos podem ser usados para realizar a atividade de hoje, e a configuração do Netkit para começá-la segue abaixo:
  
−
[[imagem:Modelo-pbx-asterisk.png|520px]]
+
<syntaxhighlight lang=text>
 +
norte[type]=pbx
 +
sul[type]=pbx
 +
fone1[type]=generic
 +
fone2[type]=generic
  
 +
norte[eth0]=tronco:ip=192.168.2.101/24
 +
sul[eth0]=tronco:ip=192.168.2.102/24
 +
norte[eth1]=lan1:ip=10.0.0.100/24
 +
sul[eth1]=lan2:ip=10.0.1.100/24
 +
fone1[eth0]=lan1:ip=10.0.0.1/24
 +
fone2[eth0]=lan2:ip=10.0.1.2/24
 +
</syntaxhighlight>
  
−
Inicialmente criaremos a infraestrutura para chamadas VoIP, a qual aumentaremos gradualmente para podermos reproduzir o modelo aqui descrito.
+
Copie a configuração acima para um arquivo com extensão ''.conf'' (ex: ''tronco.conf''), e carregue-a no Netkit. Execute a rede, e então configure o asterisk, cujos arquivos estão em /etc/asterisk. Para testar as chamadas, [[RMU-2013-1#Como_testar_chamadas_no_Netkit|use o pjsua]] ou [[Netkit#Realizando_chamadas_VoIP|siprtp]] (mais simples, mas não é capaz de registrar no Asterisk).
  
−
== Tronco SIP ==
+
* [[RMU-2013-1#Como_testar_chamadas_no_Netkit|Ajuda sobre pjsua]]
 +
* [[Netkit#Realizando_chamadas_VoIP|Ajuda sobre siprtp]]
  
−
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.
+
= 13/09: Interligando PBX Asterisk =
  
−
[[imagem:Sip-trunk.png]]
+
Nesta atividade vamos integrar os servidores Asterisk de todos os alunos no laboratório. Usaremos uma estrutura hierárquica como ilustrado abaixo:
  
−
A ativação de um entroncamento SIP entre dois PBX Asterisk pode ser feita seguindo o exemplo abaixo:
 
  
−
{| border="1" cellpadding="2"
+
[[imagem:Asterisk-hierarquia-lab3.png]]
−
!PBX
 
−
!sip.conf
 
−
!extensions.conf
 
−
|-
 
−
|'''Norte''' || <syntaxhighlight lang=text>[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</syntaxhighlight>||<syntaxhighlight lang=text> [troncoSIP]
 
−
; Ligando para a outra central e, na sequência, o "ramal" de destino
 
−
exten => _4XXX.,1,Dial(SIP/ParaSul/${EXTEN})
 
−
same=>n,Hangup</syntaxhighlight>
 
−
|-
 
−
|'''Sul'''||<syntaxhighlight lang=text>[Norte]
 
−
type=user
 
−
secret=supersercreta
 
−
host=IP_PBX_Sul
 
−
disallow=all
 
−
allow=ulaw
 
−
;canreinvite=no
 
−
directmedia=no
 
−
context=troncoSIP
 
−
qualify=yes
 
  
−
[ParaNorte]
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/pbx.netkit Arquivo de projeto do Netkit]
−
type=peer
+
** Importe-o com ''File->Import from file''.
−
fromuser=Sul
+
** [[RMU-2013-1#Como_testar_chamadas_no_Netkit|Ajuda sobre pjsua]]
−
username=Sul
+
** [[Netkit#Realizando_chamadas_VoIP|Ajuda sobre siprtp]]
−
secret=supersecreta
 
−
host=IP_PBX_Norte
 
−
disallow=all
 
−
allow=ulaw
 
−
;canreinvite=no
 
−
directmedia=yes
 
−
qualify=yes
 
−
</syntaxhighlight>||<syntaxhighlight lang=text> [troncoSIP]
 
−
;
 
−
; Ligando para a outra central e, na sequência, o "ramal" de destino
 
−
exten => _2XXX.,1,Dial(SIP/ParaNorte/${EXTEN})
 
−
same=>n,Hangup
 
−
</syntaxhighlight>
 
−
|}
 
  
−
== 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.
+
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:
  
−
= 18/09: Interligando PBX Asterisk =
+
* ''7XXX:'' números do professor
 +
* ''1XXX:'' números do aluno 1
 +
* ''2XXX:'' números do aluno 2
 +
* ''3XXX:'' números do aluno 3
 +
* ''4XXX:'' números do aluno 4
 +
* ''5XXX:'' números do aluno 5
  
−
Nesta atividade vamos integrar os servidores Asterisk de todos os alunos no laboratório. Usaremos uma estrutura hierárquica como ilustrado abaixo:
+
... e assim por diante.
  
 +
= 18/09: Investigando os protocolos envolvidos nas chamadas =
  
−
[[imagem:Asterisk-hierarquia-lab2.png]]
+
== Sinalização com SIP ==
  
 +
As chamadas que realizamos por meio do Asterisk foram iniciadas e terminadas usando [[RMU-2013-2#O_protocolo_SIP|protocolo SIP]]. Elas podem ser enquadradas em dois casos:
 +
# Chamada com intermediação de gateway de midia
 +
# Chamada com intermediação de gateway de midia, porém usando re-INVITE
  
−
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:
+
Os diagramas a seguir servem para melhor entender como ocorrem as comunicações em cada caso.  
  
−
* ''21XX:'' números do aluno 1
+
=== Chamada entre dois agentes SIP com intermediação de um gateway de media ===
−
* ''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 [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.  
+
Este caso é parecido com o anterior, que usa um proxy SIP. A diferença está na intermediação do fluxo de media, que é feita pelo gateway de media. Isso possibilita que dois agentes estabeleçam uma chamada mesmo usando codecs diferentes, pois o gateway de media fará a tradução entre codecs.
  
−
== Questões para refletir ==
+
<syntaxhighlight lang=text>
−
# 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 ?
+
Fone 1            PBX IP              Fone 2
−
# 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 ?
+
              (directmedia=no)       
 +
    |                |                |
 +
    |  INVITE      |                |
 +
    |--------------->|  INVITE      |
 +
    |  100 Trying    |--------------->|
 +
    |<---------------|  100 Trying    |
 +
    |                |<---------------|
 +
    |                |  180 Ringing  |
 +
    |  180 Ringing  |<---------------|               
 +
    |<---------------|                |     
 +
    |                |    200 Ok      |
 +
    |    200 Ok    |<---------------|
 +
    |<---------------|                |
 +
    |    ACK        |                |
 +
    |--------------->|    ACK        |
 +
    |                |--------------->|
 +
    |    RTP Media  |  RTP Media    |
 +
    |<==============>|<==============>|
 +
    |    BYE        |                |
 +
    |--------------->|    BYE        |
 +
    |                |--------------->|
 +
    |                |    200 Ok      |
 +
    |    200 Ok    |<---------------|
 +
    |<---------------|                |
 +
    |                |                |
 +
</syntaxhighlight>
  
−
= 20/09: Prática com Asterisk: aplicações e funções típicas de PBX  =
+
=== Chamada entre dois agentes SIP com intermediação de um gateway de media e uso de re-INVITE ===
  
−
Algumas funções típicas de PBX são:
+
O uso de re-invite possibilita que o fluxo de media seja estabelecido diretamente entre os agentes SIP, caso usem o mesmo codec. Assim, evita-se a carga de processamento envolvida na intermediação pelo gateway de media. Isso é feito com o envio pelo gateway de media (representado abaixo por um PBX IP) de um novo INVITE para cada agente SIP, após a sessão SIP estar estabelecida. Esse novo INVITE contém uma descrição de media (mensagem SDP embutida no corpo da mensagem INVITE) com a localização do outro agente SIP - isso é, seu endereço IP, port UDP para a stream RTP e codec a ser usado.
−
* 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:
+
<syntaxhighlight lang=text>
−
 
+
Fone 1            PBX IP              Fone 2
−
[[imagem:Recursos-pbx.png]]
+
              (directmedia=yes)       
−
<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.''
+
    |                |                |
−
 
+
    |  INVITE      |                |
−
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 desses recursos, que usaremos para implantar algumas das funções enumeradas acima.
+
    |--------------->|  INVITE      |
−
 
+
    |  100 Trying    |--------------->|
−
== Funções usando o plano de discagem ==
+
    |<---------------|  100 Trying    |
 +
    |                |<---------------|
 +
    |                |  180 Ringing  |
 +
    |  180 Ringing  |<---------------|               
 +
    |<---------------|                |     
 +
    |                |    200 Ok      |
 +
    |    200 Ok    |<---------------|
 +
    |<---------------|                |
 +
    |    ACK        |                |
 +
    |--------------->|    ACK        |
 +
    |    INVITE      |--------------->|
 +
    |<---------------|  INVITE      |
 +
    |    200 OK      |--------------->|
 +
    |--------------->|    200 OK      |
 +
    |    ACK        |<---------------|
 +
    |--------------->|    ACK        |
 +
    |                |<---------------|
 +
    |                                |
 +
    |              RTP Media          |
 +
    |<===============================>|
 +
    |    BYE        |                |
 +
    |--------------->|    BYE        |
 +
    |                |--------------->|
 +
    |                |    200 Ok      |
 +
    |    200 Ok    |<---------------|
 +
    |<---------------|                |
 +
    |                |                |
 +
</syntaxhighlight>
  
−
Para implantar funcionalidades conhecidas ou novas no Asterisk usando o plano de discagem, devem-se conhecer alguns recursos avançados. Aqui são apresentados três deles: extensões especiais, aplicações, padrões de extensões e variáveis.
+
=== Atividade ===
  
−
=== Extensões especiais ===
+
# Execute o wireshark no hospedeiro, e deixe-o capturando datagramas UDP (especifique isso em ''Capture->options'').
 +
# Realize uma chamada entre dois softphones, usando as contas do seu servidor Asterisk.
 +
# Observe as mensagens trocadas entre softphones e Asterisk (use menu ''Telephony->VoIP Calls'' e depois ''Graph''). Em particular, observe quem é o receptor e transmissor de cada mensagem SIP e também dos pacotes de midia (protocolo RTP).
 +
# Edite o arquivo ''sip.conf'' do seu Asterisk, e defina a opção ''directmedia=yes'' (isso deve estar no perfil que você definiu para as contas). Faça o Asterisk reler o ''sip.conf'': <syntaxhighlight lang=bash>
 +
rasterisk
 +
> sip reload
 +
</syntaxhighlight>
 +
# Refaça a chamada entre os softphones, e observe no wireshark as mensagens SIP e pacotes RTP. O que mudou em relação à chamada anterior ?
 +
# Em qual caso, dentre os apresentados no início da aula, cada chamada se enquadra ? O que se pode concluir quanto ao papel do Asterisk em cada caso ?
  
−
Além das extensões criadas pelo usuário, o Asterisk apresenta algumas extensões especiais, tais como:
+
== O transporte de midia com protocolo RTP ==
−
* '''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 ===
+
* [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)]
 +
* [http://tools.ietf.org/html/rfc3550 RFC 3550: RTP: A Transport Protocol for Real-Time Applications]
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/voip/rtp.pdf Capítulo 11 do livro ''SIP: Understanding the Session Initiation Protocol, 3rd ed'']
 +
* Cap. 7 do livro ''Redes de Computadores e a Internet, 5a edição'', de James Kurose.
  
−
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.
 
−
* [http://www.voip-info.org/wiki/view/Asterisk+-+documentation+of+application+commands Lista completa de aplicações do Asterisk]
 
  
−
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+BackGround Background] ====
+
O protocolo RTP (''Real-Time Protocol'') foi desenvolvido para possibilitar o transporte de datagramas de tempo-real contendo voz, video, ou outro tipo de dados, sobre IP. Tanto H.323 quanto o modelo SIP usam RTP para o transporte de media, tornando-o o padrão mais comum para comunicações desse tipo na Internet. Apesar desse protocolo não prover qualidade de serviço (i.e. ele não possui mecanismos para atender tais tipos de requisitos), ele torna possível a detecção de alguns dos problemas introduzidos por uma rede IP, tais como:
 +
* ''Perda de pacotes ''
 +
* ''Atraso fim-a-fim variável''
 +
* ''Chegada de pacotes fora de ordem''
 +
  
−
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.
+
Esses problemas não são novidade ... nós já os discutimos nas aulas sobre [[RMU-2013-1#Transmiss.C3.A3o_de_dados_multimidia|transmissão de dados multimidia]]. O que há de novo é um '''protocolo que dá subsídios para as técnicas que buscam atender requisitos de qualidade de serviço'''. Esses subsídios são informações providas pelo RTP para ajudar a identificar os problemas citados acima, as quais são:
 +
* ''Identificação do tipo do conteúdo que está sendo carregado (codec)'': isso informa ao receptor como ele deve decodificar o conteúdo transportado (ver esta [http://en.wikipedia.org/wiki/RTP_audio_video_profile tabela de identificadores de codec usados pelo RTP])
 +
* ''Numeração de sequência'': essa informação possibilita identificar pacotes perdidos ou fora de ordem.
 +
* ''Marcação de tempo (timestamp)'': com isso é possível efetuar o cálculo de variação de atraso e implementar algum mecanismo de  sincronização com a fonte (ex: atraso de reprodução).
  
−
Exemplo:
 
  
−
<syntaxhighlight lang=text>
+
Essas informações fazem parte da PDU RTP, como se pode ver a seguir:
−
exten=>666,1,Answer
 
−
same=>n,Background(hello-world)
 
−
same=>n,Hangup
 
−
</syntaxhighlight>
 
  
−
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Playback Playback] ====
+
{| border="1" cellpadding="2"
 +
!Localização do RTP na camada de transporte
 +
!Cabeçalho RTP
 +
|-
 +
|[[imagem:Rtp1.png|200px]] ||[[imagem:Rtp-header.png]]
 +
|}
  
−
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.
+
=== RTCP ===
  
−
Exemplo:
+
Além do RTP, o protocolo auxiliar RTCP (''Real-Time Control Protocol'', também definido na [http://tools.ietf.org/html/rfc3550 RFC 3550]) foi definido para o '''monitoramento da entrega dos pacotes''' (recepção da stream). Com esse protocolo, os participantes de uma sessão de media podem fazer o intercâmbio de relatórios e estatísticas. Cada tipo de relatório é transportado por um tipo de pacote RTCP. O uso de relatórios possibilita o ''feedback'' sobre a qualidade da comunicação, incluindo informações como:
 +
* Número de pacotes enviados e recebidos
 +
* Número de pacotes perdidos
 +
* ''Jitter'' (variação de atraso)
  
−
<syntaxhighlight lang=text>
+
Os cinco tipos de relatórios são:
−
exten=>666,1,Answer
+
* Relatório do transmissor (''Sender Report - SR'')
−
same=>n,Playback(hello-world)
+
* Relatório do receptor (''Receiver Report - RR'')
−
same=>n,Hangup
+
* Descrição da fonte (''Source Description - SDES'')
−
</syntaxhighlight>
+
* ''Bye''
 +
* Específico da aplicação (''Application Specific - APP'')
 +
 
 +
Como o tráfego RTCP é puramente overhead, o protocolo foi projetado para que seu consumo da capacidade da rede seja constante, não importa quantos participantes da sessão de media existam. A ideia é que quanto mais participantes houver, menos frequentemente os relatórios RTCP são enviados. Por exemplo, se em uma conferência houver somente dois participantes, os relatórios podem ser enviados a cada 5 segundos. Se houver quatro participantes, os relatórios são enviados a cada 10 segundos. Com isso o consumo de banda para relatórios se mantém constante e previsível.
 +
 
 +
=== Atividade ===
  
−
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Wait Wait] ====
+
Essa atividade busca ilustrar os fluxos RTP com um exemplo:
 +
# Estabeleça uma chamada VoIP entre dois softphones usando o Asterisk como intermediário.
 +
# Execute o wireshark no computador onde roda o Asterisk, 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 audio.
 +
# Observe os relatórios RTCP:
 +
#* Que tipos de relatórios são enviados ?
 +
#* Com que frequência esses relatórios são transmitidos ?
 +
#* Que informações esses relatórios contêm ?
  
−
Força uma espera durante o processamento da chamada.
+
= 20/09: retomando a interligação entre PBX Asterisk =
  
−
Exemplo:
+
Hoje vamos completar a atividade iniciada em 13/09, além de agregar à rede a possibilidade de fazer e receber chamadas da PSTN (tanto fixa quanto celular). Para isso usaremos os módulos EBS da Khomp.
  
−
<syntaxhighlight lang=text>
+
= 25/09: URA (Unidade de Resposta Audível) e prática com Asterisk: aplicações e funções típicas de PBX  =
−
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] ====
+
O que é uma URA (''Unidade de Resposta Audível'') ? Clique na imagem abaixo ...
  
−
Answer atende uma chamada. Hangup termina uma chamada.
+
[[imagem:Ura-tabajara.png|link=http://www.youtube.com/watch?v=VfDh2GhGnVg]]
 +
<br>''URA Tabajara''
  
−
Exemplo:
+
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>
 
<syntaxhighlight lang=text>
−
exten=>666,1,Answer
+
[default]
−
same=>n,Playback(hello-world)
+
exten => 666,1,Goto(ura,s,1)  
−
same=>n,Hangup
 
−
</syntaxhighlight>
 
  
−
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+GoTo GoTo] ====
+
[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
  
−
Pula para um contexto (opcional), extensão, prioridade específica. Exemplo:
+
exten => 1,1,NoOp(Chamada foi para Suporte)
−
<syntaxhighlight lang=text>
+
same => n,Dial(SIP/2402,60)
−
exten=>100,1,GoTo(vendas,s,1)
+
same => n, Hangup
−
</syntaxhighlight>
 
  
−
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+GoToIf GoToIf] ====
+
exten => 2,1,NoOp(Chamada foi para Comercial)
 +
same => n,Dial(SIP/2801,60)
 +
same => n, Hangup
  
−
* [http://www.voip-info.org/wiki/view/Asterisk+Expressions Expressões no Asterisk]
+
exten => 3,1,NoOp(Chamada foi para Financeiro)
 +
same => n,Dial(SIP/2000,60)
 +
same => n, Hangup
  
−
Trata-se do comando GoTo condicional. Sua sintaxe é:
+
exten => i,1,NoOp(Extensão inválida)
 +
same => n,Play(beep)
 +
same => n,GoTo(s,3); volta para o menu
  
−
'''GoToIf'''''(condição?[rótulo se verdade]:[rótulo se falso])''
+
exten => t,1,NoOp(Tempo esgotado)
 +
same => n,Dial(SIP/3401,60)
 +
same => n,Hangup
 +
</syntaxhighlight>
  
−
Os rótulos podem assumir a forma:
+
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''.
  
−
  ''[[contexto],extensão,]prioridade''
 
−
 
−
Exemplo:
 
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
−
[alunos]
+
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>
 +
 
 +
A implantação de uma URA (e de muitas outras funções típicas de PBX) 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 desses recursos, que usaremos para implantar uma URA.
 +
 
 +
== Funções usando o plano de discagem ==
  
−
exten=>6111,1,GoToIf($["${CALLERID(num)}" != "6112"]?2:4)
+
Para implantar funcionalidades conhecidas ou novas no Asterisk usando o plano de discagem, devem-se conhecer alguns recursos avançados. Aqui são apresentados três deles: extensões especiais, aplicações, padrões de extensões e variáveis.
−
same=> n,Dial(SIP/6111,30)
 
−
same=> n,Hangup
 
−
same=> n,Answer
 
−
same=> n,Playback(hello-world)
 
−
same=> n,Hangup
 
−
</syntaxhighlight>
 
  
−
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Set Set] ====
+
=== Extensões especiais ===
  
−
Modifica o valor de uma variável.
+
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.
  
−
Exemplo:
+
=== Aplicações ===
  
−
<syntaxhighlight lang=text>
+
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.
−
exten=>666,1,Set(Tentativas=1)
+
* [http://www.voip-info.org/wiki/view/Asterisk+-+documentation+of+application+commands Lista completa de aplicações do Asterisk]
−
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] ====
+
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+BackGround Background] ====
  
−
Grava um texto qualquer no log do Asterisk.
+
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:
 
Exemplo:
  
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
−
exten=>666,1,Log(DEBUG,"Chamada para 666")
+
exten=>666,1,Answer
−
same=>n,Dial(SIP/666,10)
+
same=>n,Background(hello-world)
 
same=>n,Hangup
 
same=>n,Hangup
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+NoOp NoOp] ====
+
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Playback 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:
  
−
Não faz nada, sendo útil para depurar o plano de discagem. Exemplo:
 
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
−
exten=>100,1,NoOp(${CONTEXT})
+
exten=>666,1,Answer
 +
same=>n,Playback(hello-world)
 +
same=>n,Hangup
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
=== Padrões de extensões ===
+
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Wait Wait] ====
−
*[http://www.voip-info.org/wiki/view/Asterisk+Dialplan+Patterns Tutorial sobre padrões de extensões no plano de discagem]
+
 
 +
Força uma espera durante o processamento da chamada.
  
−
Extensões podem ser representadas de forma compacta com padrões de extensões. Com esse recurso, muitas extensões podem ser atendidas com um único conjunto de regras, evitando um plano de discagem repetitivo. Por exemplo, se uma empresa possui ramais entre 100 e 199, o plano de discagem pode ser escrito assim:
+
Exemplo:
  
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
−
exten=>_1XX,1,Dial(SIP/${EXTEN})
+
exten=>666,1,Answer
 +
same=>n,Playback(hello-world)
 +
same=>n,Wait(1)
 +
same=>n,Playback(beep)
 
same=>n,Hangup
 
same=>n,Hangup
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
A extensão ''_1XX'' contida na primeira linha está escrita como um padrão (''pattern''), pois inicia com o caractere '''_'''. Os caracteres que seguem '''_''' indicam cada dígito que deve aparecer para satisfazer essa extensão. Nesse exemplo, deve aparecer ''1'' seguido de dois dígitos quaisquer entre ''0'' e ''9'' (é esse o significado do caractere ''X''). Desta forma, essa extensão atende qualquer número entre 100 e 199. Por fim, o número de fato chamado é armazenado na variável ''${EXTEN}'', que pode assim ser usada dentro da regra de discagem.
+
==== [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.
  
−
Alguns caracteres têm significado especial em padrões, como mostrado no exemplo (caractere ''X''). A tabela abaixo lista esses caracteres:
+
Exemplo:
  
−
{| border="1" cellpadding="2"
+
<syntaxhighlight lang=text>
−
!Caractere
+
exten=>666,1,Answer
−
!Descrição
+
same=>n,Playback(hello-world)
−
|-
+
same=>n,Hangup
−
|X|| Qualquer dígito entre 0 e 9
+
</syntaxhighlight>
−
|-
+
 
−
|Z|| Qualquer dígito entre 1 e 9
+
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+GoTo GoTo] ====
−
|-
+
 
−
|N|| Qualquer dígito entre 2 e 9
+
Pula para um contexto (opcional), extensão, prioridade específica. Exemplo:
−
|-
+
<syntaxhighlight lang=text>
−
|[13-6]|| Qualquer dígito entre os colchetes (no exemplo, 1,3,4,5,6)
+
exten=>100,1,GoTo(vendas,s,1)
−
|-
+
</syntaxhighlight>
−
|'''.'''||Qualquer sequência de um ou mais dígitos
+
 
−
|-
+
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+GoToIf GoToIf] ====
−
|<nowiki>!</nowiki>||Qualquer sequência de zero ou mais dígitos
 
−
|}
 
  
−
=== Variáveis ===
+
* [http://www.voip-info.org/wiki/view/Asterisk+Expressions Expressões no Asterisk]
−
* [http://www.voip-info.org/wiki/view/Asterisk+variables Variáveis do Asterisk]
 
  
−
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''.
+
Trata-se do comando GoTo condicional. Sua sintaxe é:
  
−
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.
+
'''GoToIf'''''(condição?[rótulo se verdade]:[rótulo se falso])''
−
* Para definir uma variável: ''VAR=valor''
 
−
* Para obter o valor de uma variável: ''${VAR}''
 
  
−
Existem três tipos de variáveis:
+
Os rótulos podem assumir a forma:
−
* '''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:
+
  ''[[contexto],extensão,]prioridade''
  
 +
Exemplo:
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
−
[globals]
 
−
; definicao de uma variavel global
 
−
VENDAS=SIP/6112
 
−
 
 
[alunos]
 
[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=>6111,1,GoToIf($["${CALLERID(num)}" != "6112"]?2:4)
−
exten=> 7777,1,Set(teste=1)
+
same=> n,Dial(SIP/6111,30)
−
exten=> 7777,n,NoOp(${teste})
+
same=> n,Hangup
−
exten=> 7777,n,Set(teste=$[${teste} + 1])
+
same=> n,Answer
−
exten=> 7777,n,NoOp(${teste})
+
same=> n,Playback(hello-world)
−
exten=> 7777,n,Hangup
+
same=> n,Hangup
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
== Funções implementadas no próprio Asterisk ==
+
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Set Set] ====
 +
 
 +
Modifica o valor de uma variável.
  
−
=== [http://www.voip-info.org/wiki/view/Music+on+Hold Música de espera] ===
+
Exemplo:
  
−
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.
+
<syntaxhighlight lang=text>
 +
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>
  
−
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.
+
==== [http://www.voip-info.org/wiki/view/Asterisk+cmd+Log Log] ====
  
−
<syntaxhighlight lang=bash>
+
Grava um texto qualquer no log do Asterisk.
−
# 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>
 
  
−
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'']:
+
Exemplo:
  
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
−
# configuracao no arquivo musiconhold.conf
+
exten=>666,1,Log(DEBUG,"Chamada para 666")
−
[alunos]
+
same=>n,Dial(SIP/666,10)
−
mode=files
+
same=>n,Hangup
−
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]:
+
==== [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>
 
<syntaxhighlight lang=text>
−
exten=>667,1,Set(CHANNEL(musicclass)=alunos)
+
exten=>100,1,NoOp(${CONTEXT})
−
same=>n,Answer
 
−
same=>n,MusicOnHold()
 
−
same=>n,Dial(SIP/667)
 
−
same=>n,Hangup
 
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+call+queues Filas de atendimento] ===
+
=== Padrões de extensões ===
 +
*[http://www.voip-info.org/wiki/view/Asterisk+Dialplan+Patterns Tutorial sobre padrões de extensões no plano de discagem]
  
−
Amplamente utilizadas nos sistemas de 0800. A configuração é feita no arquivo ''queues.conf'':
+
Extensões podem ser representadas de forma compacta com padrões de extensões. Com esse recurso, muitas extensões podem ser atendidas com um único conjunto de regras, evitando um plano de discagem repetitivo. Por exemplo, se uma empresa possui ramais entre 100 e 199, o plano de discagem pode ser escrito assim:
  
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
−
[fila-suporte]
+
exten=>_1XX,1,Dial(SIP/${EXTEN})
−
musicclass=default
+
same=>n,Hangup
−
strategy=ringall; roundrobin, rrmemory
 
−
timeout=10
 
−
wrapuptime=30
 
−
periodic-announce = em-breve
 
−
periodic-announce-frequency=60
 
−
member=>SIP/6111
 
−
member=>SIP/6112
 
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
No plano de discagem a fila de atendimento pode ser usada da seguinte forma:
+
A extensão ''_1XX'' contida na primeira linha está escrita como um padrão (''pattern''), pois inicia com o caractere '''_'''. Os caracteres que seguem '''_''' indicam cada dígito que deve aparecer para satisfazer essa extensão. Nesse exemplo, deve aparecer ''1'' seguido de dois dígitos quaisquer entre ''0'' e ''9'' (é esse o significado do caractere ''X''). Desta forma, essa extensão atende qualquer número entre 100 e 199. Por fim, o número de fato chamado é armazenado na variável ''${EXTEN}'', que pode assim ser usada dentro da regra de discagem.
  
−
<syntaxhighlight lang=text>
+
Alguns caracteres têm significado especial em padrões, como mostrado no exemplo (caractere ''X''). A tabela abaixo lista esses caracteres:
−
[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] ===
+
{| border="1" cellpadding="2"
 +
!Caractere
 +
!Descrição
 +
|-
 +
|X|| Qualquer dígito entre 0 e 9
 +
|-
 +
|Z|| Qualquer dígito entre 1 e 9
 +
|-
 +
|N|| Qualquer dígito entre 2 e 9
 +
|-
 +
|[13-6]|| Qualquer dígito entre os colchetes (no exemplo, 1,3,4,5,6)
 +
|-
 +
|'''.'''||Qualquer sequência de um ou mais dígitos
 +
|-
 +
|<nowiki>!</nowiki>||Qualquer sequência de zero ou mais dígitos
 +
|}
  
−
A captura possibilita que se puxe uma chamada de um colega no mesmo grupo de
+
=== Variáveis ===
−
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'']).
+
* [http://www.voip-info.org/wiki/view/Asterisk+variables Variáveis do Asterisk]
  
 +
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 [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.
 +
* Para definir uma variável: ''VAR=valor''
 +
* Para obter o valor de uma variável: ''${VAR}''
  
−
[[imagem:Call-capture.png|400px]]
+
Existem três tipos de variáveis:
−
<br>''Captura de chamadas - figura obtida de: Flávio Gonçalves. Guia de Configuração para Asterisk PBX, 5a edição.''
+
* '''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)}.''
  
−
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'':
+
Abaixo se pode ver um exemplo de plano de discagem que usa variáveis:
  
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
−
[joaozinho]
+
[globals]
−
callgroup=1
+
; definicao de uma variavel global
−
pickupgroup=1,2
+
VENDAS=SIP/6112
−
...
 
−
</syntaxhighlight>
 
  
−
=== [http://www.voip-info.org/wiki/view/Asterisk+call+parking Estacionamento de chamadas] ===
+
[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)})
  
−
O estacionamento de chamadas é feito no arquivo ''features.conf'' fazendo uso dos seguintes parâmetros:
+
; definicao de uma variavel especifica ao canal
−
* '''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.
+
exten=> 7777,1,Set(teste=1)
−
*ˆ '''parkpos''': Define o número de vagas para o estacionamento de chamadas.
+
exten=> 7777,n,NoOp(${teste})
−
* '''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.
+
exten=> 7777,n,Set(teste=$[${teste} + 1])
−
* '''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.
+
exten=> 7777,n,NoOp(${teste})
−
 
+
exten=> 7777,n,Hangup
−
 
+
</syntaxhighlight>
−
[[imagem:Parking-calls.png]]
 
−
<br>''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:
 
  
−
<syntaxhighlight lang=text>
+
== Algumas outras funções implementadas no próprio Asterisk ==
−
[vendas]
 
  
−
include=>parkedcalls
+
=== [http://www.voip-info.org/wiki/view/Music+on+Hold Música de espera] ===
  
−
exten=>6200,1,Dial(SIP/6200,30,tT)
+
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.
−
exten=>6200,n,Hangup
 
−
</syntaxhighlight>
 
  
−
== Atividade ==
+
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.
  
−
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.
+
<syntaxhighlight lang=bash>
 +
# 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>
  
−
# 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.
+
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'']:
−
# 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).
 
  
−
= 25/09: Prática com Asterisk: continuação =
+
<syntaxhighlight lang=text>
 +
# 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
 +
</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]:
  
−
= 27/09: Asterisk: URA; integração com DNS =
+
<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>
  
−
== URA ==
+
=== [http://www.voip-info.org/wiki/view/Asterisk+call+queues Filas de atendimento] ===
  
−
O que é uma URA (''Unidade de Resposta Audível'') ? Clique na imagem abaixo ...
+
Amplamente utilizadas nos sistemas de 0800. A configuração é feita no arquivo ''queues.conf'':
−
 
 
−
[[imagem:Ura-tabajara.png|link=http://www.youtube.com/watch?v=VfDh2GhGnVg]]
 
−
<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>
 
<syntaxhighlight lang=text>
−
[default]
+
[fila-suporte]
−
exten => 666,1,Goto(ura,s,1)
+
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:
  
−
[ura]
+
<syntaxhighlight lang=text>
−
exten => s,1,Answer
+
[suporte]
−
exten => s,2,NoOp(Ligação entrou na URA)
+
exten=> s,1,Set(CHANNEL(musicclass)=suporte)
−
exten => s,n,Background(/var/lib/asterisk/sounds/benvindo)
+
exten=> s,2,Playback(bem-vindo)
−
exten => s,n,NoOp(Digite a opção/1-suporte/2-comercial/3-financeiro)
+
exten=> s,3,Queue(fila-suporte)
−
exten => s,n,WaitExten(6); caso nada tenha sido digitado durante a mensagem "benvindo", espera mais 6 segundos no máximo
+
</syntaxhighlight>
  
−
exten => 1,1,NoOp(Chamada foi para Suporte)
+
== Atividade ==
−
same => n,Dial(SIP/2402,60)
 
−
same => n, Hangup
 
  
−
exten => 2,1,NoOp(Chamada foi para Comercial)
+
# Crie a URA Tabajara, conforme o vídeo visto na aula.
−
same => n,Dial(SIP/2801,60)
+
# Modifique a URA da questão 1 para que a mensagem de menu seja apresentada no máximo duas vezes.
−
same => n, Hangup
 
  
−
exten => 3,1,NoOp(Chamada foi para Financeiro)
+
== TAREFA: Leitura da semana ==
−
same => n,Dial(SIP/2000,60)
 
−
same => n, Hangup
 
  
−
exten => i,1,NoOp(Extensão inválida)
+
Leia o texto abaixo e prepare uma apresentação para próxima 4a feira - 02/10:
−
same => n,Play(beep)
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/Is_Your_Network_Ready_For_VoIP.pdf Sua rede está pronta para VoIP ?]
−
same => n,GoTo(s,3); volta para o menu
 
  
−
exten => t,1,NoOp(Tempo esgotado)
+
= 27/09 e 28/09: infraestrutura VoIP; integração com DNS =
−
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''.
 
−
 
 
−
<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 ==
 
−
 
 
−
# Crie a URA Tabajara, conforme o vídeo visto na aula.
 
−
# 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].
 
  
 
== Implantação de uma infraestrutura VoIP ==
 
== Implantação de uma infraestrutura VoIP ==
Linha 1 813: Linha 1 904:
 
=== Atividade ===
 
=== Atividade ===
  
−
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:
+
Hoje vamos implantar provedores VoIP que encaminharão chamadas de acordo com os domínios especificados nas URI SIP. Assim, cada conta SIP se vincula a um provedor de acordo com seu domínio. Os domínios são da forma ''provedorX.rmu.sj.ifsc.edu.br'', sendo ''X'' um número. Serão usadas as máquinas virtuais existentes na DMZ do câmpus - as mesmas dos seus servidores de video.
−
# 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''.
+
== Leitura complementar ==
−
# Em seu subdomínio inclua um registro SRV para apontar seu PBX Asterisk.
 
−
-->
 
  
−
== TAREFA: Leitura da semana ==
+
A integração entre PSTN e VoIP tem o potencial de estender o serviço de telefonia, com a liberdade que o modelo da Internet confere à criaçção de novos serviços e aplicações. Uma peça-chave para que essa integração ocorra é o mapeamento entre usuários VoIP e números de telefone da PSTN. O serviço ENUM foi proposto buscando atender essa necessidade, e fazendo uso do DNS. Leiam os textos abaixo para se informarem mais sobre essa proposta:
 +
* [http://en.wikipedia.org/wiki/Telephone_number_mapping ENUM na wikipedia]
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/enum.pdf ENUM: The Collision of Telephony and DNS Policy]
  
−
Para 15/05 (próxima 4a feira):
+
= 02/10: Revisão =
  
 +
A avaliação 1 será dia '''09/10''' e cobrirá os assuntos estudados até dia 02/10.
  
−
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.
+
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
  
−
<!-- = 09/05: Trabalho Asterisk =
+
É possível que haja questões na avaliação sobre o uso do Asterisk, envolvendo definição de canais SIP e plano de discagem.
  
−
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.  
+
Vejam as provas feitas em semestres anteriores:
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova2-2011-2.pdf 2011-2]
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova2-rec-2011-2.pdf 2011-2 (recuperação)]
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova2-2012-1.pdf 2012-1 (recuperação)]
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova1-2012-2.pdf 2012-2]
  
 +
== Trabalho 2 ==
  
−
O modelo da rede telefônica em cada unidade da empresa deve se compor de:
+
O 2o trabalho de RMU trata de implantar um serviço VoIP englobando várias redes. O cenário considerado contém um PBX de um provedor, que intermedia chamadas vindas de clientes. A rede do trabalho está mostrada abaixo:
−
* PBX IP Asterisk
 
−
* telefones IP, softphones e telefones convencionais
 
−
* ao menos um tronco analógico para a PSTN
 
−
* um link para Internet
 
  
 +
[[imagem:Rmu-Trab-2013-2.png|600px]]
 +
<br>''A rede com os PBX e telefones IP''
  
−
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.
+
Os clientes do provedor possuem seus próprios PBX IP, que interagem com os PBX dos provedores por meio de troncos SIP ou IAX2. O PBX cliente A possui também uma URA, que possibilita encaminhar chamadas para setores de suporte ou vendas (as chamadas devem ser gravadas). Esses serviços devem ser implantados usando-se o Netkit, e para isso o arquivo de configuração da rede segue abaixo:
  
−
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:
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/trab2-2013-2.netkit '''trab2-2013-2.netkit''':] Arquivo de configuração do Netkit
−
# Os troncos entre PBX das unidades da empresa devem ser IAX2.
+
** Importe-o por meio do menu ''File->Import from file''.
−
# 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.
+
** Sempre ao final de de um experimento execute ''File->Export'' após terminar a rede. Isso fará um backup do seu projeto, incluindo a configuração do Asterisk nos PBX e o arquivo ''/root/pjsua.cfg'' em cada uma das máquinas virtuais ''fone''.
−
# 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.
 
  
−
'''Orientações:'''
+
O Provedor 1 tem código de área 48, e o provedor 2 tem código de área 49. Para fazer uma chamada para um número de outro provedor deve-se prefixá-lo com ''0+código de área''.
−
* 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 ==
+
As numerações dos clientes são da seguinte forma:
 +
* 4 dígitos definidos pelo provedor para representar o cliente, seguidos de 4 dígitos que são definidos pelo cliente.
  
 +
== Como testar chamadas no Netkit ==
  
−
'''OBS:''' para ativar o endereço IP de sua equipe, execute o seguinte comando no sistema hospedeiro:
+
O Netkit possui duas ferramentas que simulam chamadas:
−
<syntaxhighlight lang=bash>
+
* '''siprtp''': esse programa possibilita fazer chamadas com áudio sintetizado, no entanto possui algumas restrições para ser usado com o Asterisk ([[Netkit#Realizando_chamadas_VoIP|maiores detalhes]]).
−
sudo ifconfig eth0 IP_da_sua_equipe
+
* '''pjsua''': esse programa é mais completo, sendo capaz de realizar chamadas muito próximas do real. Ele é até capaz de gerar o audio a partir de arquivos de som. Ao contrário do ''siprtp'', o ''pjsua'' é capaz de se registrar no Asterisk.
−
sudo route add default gw 192.168.2.1
+
** [http://www.pjsip.org/pjsua.htm Manual do pjsua]
−
</syntaxhighlight>
 
  
−
== Como criar a rede de desenvolvimento ==
+
Note também que a configuração da rede conecta os switches das LANs dos clientes à rede real (ver switch ''brige''). Com isso é possível efetuar testes com telefones IP ou softphones, realizando de fato chamadas VoIP.
  
−
A rede de cada unidade da empresa tem uma estrutura como mostrado na seguinte figura:
+
=== Usando o pjsua ===
  
−
[[imagem:Trab-asterisk-1.png]]
+
O pjsua possui muitas funcionalidades que o tornam um agente SIP quase completo (faltaria ao menos suportar re-invite). Para usá-lo existem muitas opções de linha de comando, conforme descrito em [http://www.pjsip.org/pjsua.htm seu manual]. Aqui se demonstra como fazer uma chamada com dois pjsua registrados em um PBX Asterisk.
  
 +
# Inicie o Asterisk nos PBX, executando este comando em cada um deles: <syntaxhighlight lang=bash>
 +
asterisk
 +
rasterisk -vvv
 +
</syntaxhighlight>''Obs: "rasterisk -vvv" serve somente para que você possa monitorar o funcionamento do Asterisk''
 +
# Em cada máquina virtual ''fone'' existe um arquivo ''/root/pjsua.cfg'', que contém configurações usuais para rodar o pjsua. Desta forma, evita-se ter que digitá-las sempre que se iniciar o programa. Deve-se executar o pjsua da seguinte forma para que use esse arquivo de configuração: <syntaxhighlight lang=bash>
 +
pjsua --config-file=/root/pjsua.cfg
 +
</syntaxhighlight>
 +
# O arquivo de configuração tenta registrar automaticamente o pjsua no Asterisk. As contas SIP pre-configuradas para fins de demonstração são:
 +
#* ''sip:100@ifsc.edu.br'': em fone1, fone3 e fone5.
 +
#* ''sip:101@ifsc.edu.br'': em fone2, fone4 e fone6.
 +
# Ao rodar o pjsua, confira no PBX correspondente se ele foi devidamente registrado. Assim, execute o seguinte no prompt do rasterisk desse PBX: <syntaxhighlight lang=bash>
 +
sip show peers
 +
</syntaxhighlight>O resultado deve ser parecido com este (no meu caso, eu ativei dois pjsua), em que se nota o Status ''OK'' para as contas SIP:<br><br>[[imagem:Rasterisk1.png|600px]]<br><br>
 +
# A tela do pjsua mostra um menu com os comandos que podem ser usados, como mostrado na seguinte figura: <br><br>[[imagem:Pjsua1.png|600px]]<br><br>
 +
# Para fazer uma chamada, use o comando '''m'''. Ao digitá-lo e teclar ENTER, será pedida a URL do contato a ser chamado: <br><br>[[imagem:Pjsua2.png|600px]]<br><br>
 +
# Uma vez tendo a chamada estabelecida, pode-se usar o comando '''dq''' para monitorar a qualidade da comunicação:<br><br>[[imagem:Pjsua3.png|600px]]<br><br>
 +
# Para encerrar a chamada, use o comando '''ha'''.
  
−
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:
+
==== Ajustes na configuração do pjsua ====
  
 +
O arquivo de configuração pjsua.cfg que foi fornecido contém configuração de demonstração. Ao fazer as suas modificações nas configurações dos PBX para realizar o trabalho, será necessário também ajustar esse arquivo. Abaixo segue o conteúdo do pjsua.cfg que está em ''fone1'':
  
−
[[imagem:Trab-asterisk-2.png]]
+
<syntaxhighlight lang=text n>
 +
#
 +
# User agent:
 +
#
 +
--auto-answer 200
 +
--max-calls 4
 +
--registrar sip:192.168.1.100
 +
--proxy sip:192.168.1.100;lr
 +
--realm *
 +
# Abaixo devem ser especificados os dados da conta SIP
 +
--id sip:100@ifsc.edu.br
 +
--username 100
 +
--password 100
  
 +
#
 +
# Logging options:
 +
#
 +
--log-level 3
 +
--app-log-level 4
  
−
# 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.
+
#
−
# Na VM faça o seguinte:
+
# Network settings:
−
## 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>
+
--local-port 5060
−
auto lo eth0
 
−
 
 
−
iface lo inet loopback
 
  
−
iface eth0 inet dhcp
+
#
−
</syntaxhighlight>
+
# Media settings:
−
## 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
+
--null-audio
−
</syntaxhighlight>
+
--snd-auto-close 1
 +
--rtp-port 4000
  
−
== Como criar o tronco IAX2 ==
+
#
 +
# SIP extensions:
 +
#
 +
--use-timer 1
  
−
Para criar o tronco IAX2 com os demais PBX, insira a seguinte configuração em /etc/asterisk/iax.conf:
+
# Desativa deteccao de silencio
−
 
+
--no-vad
−
<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>
 
</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:
+
O que pode ser necessário modificar são os dados da conta SIP a ser usada pelo pjsua. Isso é especificado nas linhas 10, 11 e 12.
  
−
<syntaxhighlight lang=text>
+
== Entrega do trabalho ==
−
exten=>33812850,1,Dial(IAX2/EquipeXX-YY/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.  
+
O trabalho deve ser entregue até dia '''16/10'''. Ele pode ser realizado por equipes de até duas pessoas. A entrega deve ser composta de:
 +
* Um relatório explicando como foi implantado todo o serviço VoIP, explicando as regras de discagem e o cadastro dos telefones IP.
 +
* Um arquivo de projeto do Netkit contendo as configurações realizadas. Esse arquivo deve ser gerado pelo menu ''File->Export'', após encerrar a execução da rede no Netkit.
  
−
-->
+
''Obs:'' eu posso fazer questionamentos aos membros das equipes para esclarecer o que foi feito no trabalho.
  
−
= 02/10: Trabalho 1 =
+
= 04/10: Introdução à qualidade de serviço (Qos) =
  
−
O 1o trabalho de RMU trata de implantar um serviço VoIP englobando várias redes. O cenário considerado contém um PBX de um provedor, que intermedia chamadas vindas de clientes. Além disso, o PBX do provedor provê um serviço de audio-conferência. A rede do trabalho está mostrada abaixo:
+
* [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.teleco.com.br/tutoriais/tutorialvoipconv2/pagina_2.asp Tutorial sobre QoS para VoIP]
  
−
[[imagem:Rmu-Trab-2013-1.png|600px]]
+
Como medir a qualidade de serviço de uma rede ?
−
<br>''A rede com os PBX e telefones IP''
+
* Disponibilidade ?
 +
* Largura de banda
 +
* Latência (atraso fim-a-fim)
 +
* Variação de atraso (jitter)
 +
* Perda de pacotes
  
  
−
Os clientes do provedor possuem seus próprios PBX IP, que interagem com o PBX do provedor por meio de um tronco SIP ou IAX2. Cada PBX de cliente implementa serviços de captura de chamadas. O PBX cliente A possui também uma URA, que possibilita encaminhar chamadas para setores de suporte, vendas e compras. Esses serviços devem ser implantados usando-se o Netkit, e para isso o arquivo de configuração da rede segue abaixo:
+
[[imagem:Rmu-tabela-qos.png]]
 +
<br>''Um comparativo de requisitos de QoS de algumas aplicações''
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/trab-2013-1.netkit '''trab-2013-1.netkit''':] Arquivo de configuração do Netkit
 
−
** Importe-o por meio do menu ''File->Import from file''.
 
−
** Sempre ao final de de um experimento execute ''File->Export'' após terminar a rede. Isso fará um backup do seu projeto, incluindo a configuração do Asterisk nos PBX e o arquivo ''/root/pjsua.cfg'' em cada uma das máquinas virtuais ''fone''.
 
  
−
As numerações dos clientes são da seguinte forma:
+
* '''Como prover QoS ?'''
−
* 4 dígitos definidos pelo provedor para representar o cliente (sendo que o primeiro dígito deve ser 7), seguidos de 4 dígitos que são definidos pelo cliente.
 
  
−
== Como testar chamadas no Netkit ==
+
[[imagem:Qos-tarefas.png|600px]]
  
−
O Netkit possui duas ferramentas que simulam chamadas:
 
−
* '''siprtp''': esse programa possibilita fazer chamadas com áudio sintetizado, no entanto possui algumas restrições para ser usado com o Asterisk ([[Netkit#Realizando_chamadas_VoIP|maiores detalhes]]).
 
−
* '''pjsua''': esse programa é mais completo, sendo capaz de realizar chamadas muito próximas do real. Ele é até capaz de gerar o audio a partir de arquivos de som. Ao contrário do ''siprtp'', o ''pjsua'' é capaz de se registrar no Asterisk.
 
−
** [http://www.pjsip.org/pjsua.htm Manual do pjsua]
 
  
−
Note também que a configuração da rede conecta os switches das LANs dos clientes à rede real (ver switch ''brige''). Com isso é possível efetuar testes com telefones IP ou softphones, realizando de fato chamadas VoIP.
+
== Uma pequena experiência ==
  
−
=== Usando o pjsua ===
+
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''.
 +
# Para fazer o download: <syntaxhighlight lang=bash>
 +
wget http://tele.sj.ifsc.edu.br/~msobral/ubuntu.iso
 +
</syntaxhighlight>
 +
# Para ver o video execute: <syntaxhighlight lang=bash>
 +
vlc http://172.18.20.251/~msobral/video.avi
 +
</syntaxhighlight>
  
−
O pjsua possui muitas funcionalidades que o tornam um agente SIP quase completo (faltaria ao menos suportar re-invite). Para usá-lo existem muitas opções de linha de comando, conforme descrito em [http://www.pjsip.org/pjsua.htm seu manual]. Aqui se demonstra como fazer uma chamada com dois pjsua registrados em um PBX Asterisk.
+
* Qual a taxa de download que foi obtida ?
 +
* Como se desempenhou a reprodução do video ?
  
−
# Inicie o Asterisk nos PBX, executando este comando em cada um deles: <syntaxhighlight lang=bash>
 
−
asterisk
 
−
rasterisk -vvv
 
−
</syntaxhighlight>''Obs: "rasterisk -vvv" serve somente para que você possa monitorar o funcionamento do Asterisk''
 
−
# Em cada máquina virtual ''fone'' existe um arquivo ''/root/pjsua.cfg'', que contém configurações usuais para rodar o pjsua. Desta forma, evita-se ter que digitá-las sempre que se iniciar o programa. Deve-se executar o pjsua da seguinte forma para que use esse arquivo de configuração: <syntaxhighlight lang=bash>
 
−
pjsua --config-file=/root/pjsua.cfg
 
−
</syntaxhighlight>
 
−
# O arquivo de configuração tenta registrar automaticamente o pjsua no Asterisk. As contas SIP pre-configuradas para fins de demonstração são:
 
−
#* ''sip:100@ifsc.edu.br'': em fone1, fone3 e fone5.
 
−
#* ''sip:101@ifsc.edu.br'': em fone2, fone4 e fone6.
 
−
# Ao rodar o pjsua, confira no PBX correspondente se ele foi devidamente registrado. Assim, execute o seguinte no prompt do rasterisk desse PBX: <syntaxhighlight lang=bash>
 
−
sip show peers
 
−
</syntaxhighlight>O resultado deve ser parecido com este (no meu caso, eu ativei dois pjsua), em que se nota o Status ''OK'' para as contas SIP:<br><br>[[imagem:Rasterisk1.png|600px]]<br><br>
 
−
# A tela do pjsua mostra um menu com os comandos que podem ser usados, como mostrado na seguinte figura: <br><br>[[imagem:Pjsua1.png|600px]]<br><br>
 
−
# Para fazer uma chamada, use o comando '''m'''. Ao digitá-lo e teclar ENTER, será pedida a URL do contato a ser chamado: <br><br>[[imagem:Pjsua2.png|600px]]<br><br>
 
−
# Uma vez tendo a chamada estabelecida, pode-se usar o comando '''dq''' para monitorar a qualidade da comunicação:<br><br>[[imagem:Pjsua3.png|600px]]<br><br>
 
−
# Para encerrar a chamada, use o comando '''ha'''.
 
  
−
==== Ajustes na configuração do pjsua ====
+
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 arquivo de configuração pjsua.cfg que foi fornecido contém configuração de demonstração. Ao fazer as suas modificações nas configurações dos PBX para realizar o trabalho, será necessário também ajustar esse arquivo. Abaixo segue o conteúdo do pjsua.cfg que está em ''fone1'':
+
* Qual a nova taxa de download obtida ?
−
 
+
* Como se desempenhou a reprodução do video desta vez ?
−
<syntaxhighlight lang=text n>
 
−
#
 
−
# User agent:
 
−
#
 
−
--auto-answer 200
 
−
--max-calls 4
 
−
--registrar sip:192.168.1.100
 
−
--proxy sip:192.168.1.100;lr
 
−
--realm *
 
−
# Abaixo devem ser especificados os dados da conta SIP
 
−
--id sip:100@ifsc.edu.br
 
−
--username 100
 
−
--password 100
 
  
−
#
+
== Uma outra experiência ==
−
# Logging options:
 
−
#
 
−
--log-level 3
 
−
--app-log-level 4
 
  
−
#
+
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:
−
# Network settings:
+
# Execute o Jitsi ou use um telefone IP, registrando-o em 172.18.20.251 com o ramal 20001 a 2010 (com senha=número_do_ramal).
−
#
+
# Faça este download:<syntaxhighlight lang=bash>
−
--local-port 5060
+
wget http://172.18.20.251/~msobral/rmu.bin
 +
</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''.
  
−
#
+
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.
−
# Media settings:
 
−
#
 
−
--null-audio
 
−
--snd-auto-close 1
 
−
--rtp-port 4000
 
  
−
#
+
* Qual a nova taxa de download obtida ?
−
# SIP extensions:
+
* Que qualidade se obteve para as streams RTP desta vez ?
−
#
+
 
−
--use-timer 1
+
= 09/10: Avaliação 1 =
  
−
# Desativa deteccao de silencio
+
A avaliação 1 cobrirá os assuntos estudados até dia 02/10.
−
--no-vad
 
−
</syntaxhighlight>
 
  
−
O que pode ser necessário modificar são os dados da conta SIP a ser usada pelo pjsua. Isso é especificado nas linhas 10, 11 e 12.
+
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
  
−
== Entrega do trabalho ==
+
É possível que haja questões na avaliação sobre o uso do Asterisk, envolvendo definição de canais SIP e plano de discagem.
  
−
O trabalho deve ser entregue até dia '''29/05'''. Ele pode ser realizado por equipes de até duas pessoas. A entrega deve ser composta de:
+
Vejam as provas feitas em semestres anteriores:
−
* Um relatório explicando como foi implantado todo o serviço VoIP, explicando as regras de discagem e o cadastro dos telefones IP.
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova2-2011-2.pdf 2011-2]
−
* Um arquivo de projeto do Netkit contendo as configurações realizadas. Esse arquivo deve ser gerado pelo menu ''File->Export'', após encerrar a execução da rede no Netkit.
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova2-rec-2011-2.pdf 2011-2 (recuperação)]
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova2-2012-1.pdf 2012-1 (recuperação)]
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova1-2012-2.pdf 2012-2]
  
−
''Obs:'' eu posso fazer questionamentos aos membros das equipes para esclarecer o que foi feito no trabalho.
+
= 11/10: Conceitos básicos sobre QoS =
  
−
= 04/10: Introdução à qualidade de serviço (Qos) =
+
== Provendo QoS: conceitos básicos ==
  
 
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-03.pdf Transparências]
 
* [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.scribd.com/doc/57127868/Cisco-QoS-Concept-and-Design Cisco QoS Concept and Design]
−
* [http://www.teleco.com.br/tutoriais/tutorialvoipconv2/pagina_2.asp Tutorial sobre QoS para VoIP]
+
* [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)]
  
−
Como medir a qualidade de serviço de uma rede ?
+
Como PROVER qualidade de serviço em uma rede ?
−
* Disponibilidade ?
+
* Como classificar os pacotes, para que sejam tratados de acordo com os requisitos de QoS especificados ?
−
* Largura de banda
+
* Como garantir banda para um determinada classe de tráfego ?
−
* Latência (atraso fim-a-fim)
+
* Como limitar o uso de banda ?
−
* Variação de atraso (jitter)
+
* Como limitar o atraso fim-a-fim de pacotes ?
−
* Perda 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.
  
−
[[imagem:Rmu-tabela-qos.png]]
+
[[imagem:Filas-roteador.png]]
−
<br>''Um comparativo de requisitos de QoS de algumas aplicações''
 
  
  
−
* '''Como prover QoS ?'''
+
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'');.
  
−
[[imagem:Qos-tarefas.png|600px]]
 
  
 +
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]].
  
−
== Uma pequena experiência ==
+
=== Exercícios ===
  
−
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''.
+
Resolver os exercícios propostos no final das [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-03.pdf transparências].
−
# Para fazer o download: <syntaxhighlight lang=bash>
 
−
wget http://tele.sj.ifsc.edu.br/~msobral/ubuntu.iso
 
−
</syntaxhighlight>
 
−
# Para ver o video execute: <syntaxhighlight lang=bash>
 
−
vlc http://172.18.80.251/~msobral/video.avi
 
−
</syntaxhighlight>
 
  
−
* Qual a taxa de download que foi obtida ?
+
''OBS:'' para o problema de enfileiramentos RR e WFQ:
−
* Como se desempenhou a reprodução do video ?
+
* classe 1 (peso 2 no caso do WFQ) = pacotes 2,3,6,8,9,12
 +
* classe 2 (peso 4 no caso do WFQ) = pacotes 4,5,7,10,11
  
 +
No caso do enfileiramento com prioridades: pacotes ímpares são mais prioritários.
  
−
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.
+
<!-- = 18/10: Simulação com Opnet =
  
−
* Qual a nova taxa de download obtida ?
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-04.pdf Roteiro da aula]
−
* Como se desempenhou a reprodução do video desta vez ?
 
  
−
== Uma outra experiência ==
+
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.
  
−
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:
 
−
# Execute o Jitsi ou use um telefone IP, registrando-o em 192.168.2.101 com o ramal 200+número_do_seu_computador (com senha=número_do_ramal).
 
−
# Faça este download:<syntaxhighlight lang=bash>
 
−
wget http://172.18.80.251/~msobral/rmu.bin
 
−
</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''.
 
  
−
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.  
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/opnet.tgz Instalador do Opnet (basta descompactar em /home/aluno)]
 +
** [http://tele.sj.ifsc.edu.br/~msobral/rmu/opnet_licenca.tgz Licenca do Opnet (caso você já tenha instalado o simulador ... descompacte-o em /home/aluno)]
  
−
* Qual a nova taxa de download obtida ?
+
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.
−
* Que qualidade se obteve para as streams RTP desta vez ?
 
  
−
= 09/10: revisão =
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/opnet Script para executar o simulador]
  
−
...
 
  
−
= 11/10: Avaliação 1 =
+
[[imagem:Rmu-opnet.png|600px]]
  
−
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:
+
Os modelos de simulação criados ficam localizados em:
−
# ''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
 
  
−
É possível que haja questões na avaliação sobre o uso do Asterisk, envolvendo definição de canais SIP e plano de discagem.
+
.cxoffice/Unsupported/drive_c/windows/temp/op_models
  
−
Vejam as provas feitas em semestres anteriores:
+
Assim, pode-se fazer um backup dos modelos caso necessário.
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova2-2011-2.pdf 2011-2]
 
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova2-rec-2011-2.pdf 2011-2 (recuperação)]
 
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova2-2012-1.pdf 2012-1 (recuperação)]
 
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova1-2012-2.pdf 2012-2]
 
  
−
= 16/10: Conceitos básicos sobre QoS =
+
== TAREFA: leitura de um texto ==
  
−
== Provendo QoS: conceitos básicos ==
+
Leiam este texto sobre um problema relacionado aos atrasos de transmissão percebidos na Internet:
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-03.pdf Transparências]
+
* [http://cacm.acm.org/magazines/2012/2/145415-bufferbloat-whats-wrong-with-the-internet/fulltext Bufferbloat: What is wrong with the Internet ?]
−
* [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)]
 
  
−
Como PROVER qualidade de serviço em uma rede ?
+
Na aula de 4a feira (12/06) sortearei um aluno para explicar o conteúdo desse artigo.
−
* 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 ?
+
<!-- == TAREFA: leitura da semana ... ==
−
* 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.
+
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] -->
  
−
[[imagem:Filas-roteador.png]]
+
= 18/10: QoS em um roteador Linux =
  
 +
* [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).
  
−
Algumas técnicas conhecidas podem ser usadas para atender os requisitos acima:
+
== Disciplinas de filas (''qdisc'') ==
−
* '''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'');.
 
  
 +
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.
  
−
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]].
+
[[imagem:Rmu-Qdisc-overview.png|800px]]
 +
<br>''Visão geral do enfileiramento de pacotes em uma interface de saída''
  
−
=== Exercícios ===
+
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.
 +
* '''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])
  
−
Resolver os exercícios propostos no final das [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-03.pdf transparências].
+
Os diagramas abaixo ilustram algumas dessas ''qdisc'':
  
−
''OBS:'' para o problema de enfileiramentos RR e WFQ:
+
[[imagem:Rmu-Prio-qdisc.gif|600px]]
−
* classe 1 (peso 2 no caso do WFQ) = pacotes 2,3,6,8,9,12
+
<br>''Uma disciplina de filas baseada em prioridades. Fonte: [http://opalsoft.net/qos/DS.htm Differentiated Service on Linux HOWTO]''
−
* classe 2 (peso 4 no caso do WFQ) = pacotes 4,5,7,10,11
 
  
−
No caso do enfileiramento com prioridades: pacotes ímpares são mais prioritários.
 
  
−
= 18/10: Simulação com Opnet =
+
[[imagem:Rmu-Tbf-qdisc.gif|400px]]
 +
<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]''
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-04.pdf Roteiro da aula]
+
== Atividade ==
  
−
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.
+
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
  
 +
[[imagem:Rede-qos-rtp.png]]
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/opnet.tgz Instalador do Opnet (basta descompactar em /home/aluno)]
 
−
** [http://tele.sj.ifsc.edu.br/~msobral/rmu/opnet_licenca.tgz Licenca do Opnet (caso você já tenha instalado o simulador ... descompacte-o em /home/aluno)]
 
  
−
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.
+
A rede a ser usada deve ser criada no [[Netkit]], a partir da configuração abaixo:
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/opnet Script para executar o simulador]
 
  
 +
{{collapse top|Arquivo de configuração do Netkit (copie-o para dentro de Lab.conf)}}
 +
<syntaxhighlight lang=text>
 +
# 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
 +
</syntaxhighlight>
 +
{{collapse bottom}}
  
−
[[imagem:Rmu-opnet.png|600px]]
+
=== Roteiro ===
−
 
 
  
−
Os modelos de simulação criados ficam localizados em:
+
1) Antes de mais nada, deve-se limitar a banda do enlace ponto-a-ponto (entre r1 e r2) a 256 kbps. Crie o arquivo /root/qdisc.sh em cada um desses roteadores, e grave neles o seguinte:
 +
<syntaxhighlight lang=bash>
 +
#!/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
 +
</syntaxhighlight>''Obs:'' isso implanta uma qdisc do tipo HTB (ser vista com detalhes numa aula posterior) para fazer a limitação de banda. Após criar o arquivo ''/root/qdisc.sh'', execute-o: <syntaxhighlight lang=bash>
 +
bash /root/qdisc.sh
 +
</syntaxhighlight>
  
−
.cxoffice/Unsupported/drive_c/windows/temp/op_models
+
2) 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:
−
 
+
* Em ''server2'' executa-se o ''siprtp'' em modo servidor: <syntaxhighlight lang=bash>
−
Assim, pode-se fazer um backup dos modelos caso necessário.
+
siprtp --ip-addr=192.168.1.2
−
 
+
</syntaxhighlight>
−
== TAREFA: leitura de um texto ==
+
* 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>
−
Leiam este texto sobre um problema relacionado aos atrasos de transmissão percebidos na Internet:
+
siprtp --ip-addr=192.168.2.1 sip:0@192.168.1.2
−
 
+
</syntaxhighlight>
−
* [http://cacm.acm.org/magazines/2012/2/145415-bufferbloat-whats-wrong-with-the-internet/fulltext Bufferbloat: What is wrong with the Internet ?]
+
* 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
−
Na aula de 4a feira (12/06) sortearei um aluno para explicar o conteúdo desse artigo.
+
List all calls:
−
 
+
Call #0: CONFIRMED [duration: 00:00:01.643]
−
<!-- == TAREFA: leitura da semana ... ==
+
  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''.
  
−
Leiam este textos e preparem-se para apresentá-los em 11/12:
+
3) 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'':
−
*[http://www.informit.com/articles/article.aspx?p=352991&seqNum=8 WRED]
+
* Crie um arquivo de 16 MB em ''server1'': <syntaxhighlight lang=bash>
−
*[http://searchnetworking.techtarget.com/tip/LAN-QoS-Access-switches-get-intelligent-for-high-stakes-applications LAN QoS] -->
+
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.
  
−
= 23/10: QoS em um roteador Linux =
+
4) 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 ''eth1''. 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 ''/root/qdisc.sh'':<syntaxhighlight lang=bash>
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-13.pdf Transparências]
+
#!/bin/bash
−
* [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).
+
# Limpa as qdisc que porventura existam
−
 
+
tc qdisc del dev eth1 root
−
== Disciplinas de filas (''qdisc'') ==
+
 +
# 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
  
−
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.  
+
</syntaxhighlight>... e em seguida execute-o: <syntaxhighlight lang=bash>
 +
bash /root/qdisc.sh
 +
</syntaxhighlight>
 +
* Repita o ítem 2, e observe as perdas de pacotes e ''jitter'' da chamada VoIP. Houve melhora ?
  
−
[[imagem:Rmu-Qdisc-overview.png|800px]]
+
5) Pela capacidade do link é possível haver mais de uma chamada VoIP. Sendo assim:
−
<br>''Visão geral do enfileiramento de pacotes em uma interface de saída''
+
* 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>
  
−
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:
+
6) E se for desejável limitar o atendimento com qualidade de até quatro chamadas, deixando o restante da capacidade do link para transferências de dados ? Pense numa forma de fazer isso usando as disciplinas de filas do Linux (''dica: veja a qdisc TBF'').
−
* '''FIFO:''' pacotes saem por ordem de chegada.
+
* Implemente essa limitação nos roteadores.
−
* '''PRIO:''' pacotes saem de acordo com prioridades.
+
* Teste qual a taxa disponível para transferências de dados.
−
* '''SFQ (Stochastic Fair Queueing):''' pacotes saem de forma que os fluxos a que pertencem recebam aproximadamente a mesma taxa de bits.
+
* verifique se até quatro chamadas simultâneas podem ser atendidas a contento.
−
* '''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'':
+
<!--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>
  
−
[[imagem:Rmu-Prio-qdisc.gif|600px]]
+
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>
−
<br>''Uma disciplina de filas baseada em prioridades. Fonte: [http://opalsoft.net/qos/DS.htm Differentiated Service on Linux HOWTO]''
+
# 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
  
 +
# 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
  
−
[[imagem:Rmu-Tbf-qdisc.gif|400px]]
+
# Demais datagramas vão para a fila intermediária.
−
<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]''
+
tc filter add dev eth0 parent 1: prio 2 protocol ip u32 match ip src 0.0.0.0/0 flowid 1:2
 +
</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.
 +
# -- 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
  
−
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:
+
# Balanceia os fluxos nas duas filas da qdisc PRIO que serão usadas
−
* Uma transferência de um arquivo com HTTP
+
tc qdisc add dev eth0 parent 1:1 handle 2:0 sfq
−
* Uma chamada VoIP com SIP e RTP
+
tc qdisc add dev eth0 parent 1:2 handle 3:0 sfq
  
−
[[imagem:Rede-qos-rtp.png]]
+
# 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>
  
−
A rede a ser usada deve ser criada no [[Netkit]], a partir da configuração abaixo:
+
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.
  
 +
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.
 +
-->
 +
 +
<!-- == TAREFA: leitura da semana ==
  
−
{{collapse top|Arquivo de configuração do Netkit (copie-o para dentro de Lab.conf)}}
+
O texto a seguir continua a leitura desta semana, tratando da implantação de uma estrutura Diffserv na borda da rede.
−
<syntaxhighlight lang=text>
+
* [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)'']
−
# Global attributes: these values are obtained automatically from menu General->Preferences
+
-->
−
global[mem]=32
+
 
−
global[compact]=False
+
= 30/10: QoS em roteador Linux =
−
global[vm]=0
+
 
−
global[clean]=False
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-13.pdf Transparências]
−
# 32 MB por VM
+
* [http://opalsoft.net/qos/DS.htm Um bom tutorial sobre disciplinas de filas no Linux]
−
# Não remove o diretório de trabalho ao final da execução
+
* [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 ]
−
server1[type]=generic
+
 
−
server2[type]=generic
+
== ''qdisc'' com estado (''stateful'') ==
−
pc[type]=generic
+
 
−
r1[type]=gateway
+
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.
−
r2[type]=gateway
+
 
−
+
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:
−
# Rede 1: servidores + roteador r1
+
* '''WWW (http e https):''' 40 kbps
−
server1[eth0]=rede1:ip=192.168.1.1/24
+
* '''SSH:''' 40 kbps
−
server2[eth0]=rede1:ip=192.168.1.2/24
+
* '''Demais aplicações:''' 20 kbps
−
r1[eth0]=rede1:ip=192.168.1.254/24
+
 
−
+
 
−
# Rede 2: pc + roteador r2
+
O diagrama abaixo mostra como poderia ser modelada a limitação de banda para essas aplicações:
−
r2[eth0]=rede2:ip=192.168.2.254/24
+
 
−
pc[eth0]=rede2:ip=192.168.2.1/24
+
 
−
+
[[imagem:Qdisc-ex1.png]]
−
# 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
+
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:
−
+
 
−
# Roteadores default dos servidores e pc
+
 
−
server1[default_gateway]=192.168.1.254
+
[[imagem:Qdisc-ex1-diagram.png]]
−
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
 
−
</syntaxhighlight>
 
−
{{collapse bottom}}
 
  
−
=== Roteiro ===
 
  
−
1) Antes de mais nada, deve-se limitar a banda do enlace ponto-a-ponto (entre r1 e r2) a 256 kbps. Crie o arquivo /root/qdisc.sh em cada um desses roteadores, e grave neles o seguinte:
 
 
<syntaxhighlight lang=bash>
 
<syntaxhighlight lang=bash>
−
#!/bin/bash
+
# adiciona a qdisc raiz na interface eth0
−
+
tc qdisc add dev eth0 root handle 1:0 htb default 23
−
# Limpa as qdisc que porventura existam
+
 
−
tc qdisc del dev eth1 root
+
# 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 uma qdisc HTB (Hierarchical Token Bucket) para limitar a saída a uma taxa comparável
+
 
−
# a do link ponto-a-ponto
+
# cria as classes das aplicações
−
tc qdisc add dev eth1 root handle 1: htb default 1
+
tc class add dev eth0 parent 1:1 classid 1:21 htb rate 40kbps ceil 100kbps
−
tc class add dev eth1  parent 1: classid 1:1 htb rate 256kbit ceil 256kbit
+
tc class add dev eth0 parent 1:1 classid 1:22 htb rate 40kbps ceil 100kbps
−
</syntaxhighlight>''Obs:'' isso implanta uma qdisc do tipo HTB (ser vista com detalhes numa aula posterior) para fazer a limitação de banda. Após criar o arquivo ''/root/qdisc.sh'', execute-o: <syntaxhighlight lang=bash>
+
tc class add dev eth0 parent 1:1 classid 1:23 htb rate 20kbps ceil 100kbps
−
bash /root/qdisc.sh
+
 
 +
# 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
 
</syntaxhighlight>
 
</syntaxhighlight>
  
−
2) 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:
+
A ''qdisc'' HTB funciona da seguinte forma:
−
* Em ''server2'' executa-se o ''siprtp'' em modo servidor: <syntaxhighlight lang=bash>
+
* Cada classe possui uma taxa garantida e uma taxa máxima.
−
siprtp --ip-addr=192.168.1.2
+
* 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.
−
</syntaxhighlight>
+
* Cada classe pode emprestar banda adicional de sua classe mãe até o limite especificado por sua taxa máxima.
−
* Em um dos roteadores deve-se executar o ''wireshark'' (ver menu ''Wireshark''), escolhendo-se a interface ''eth0''.
+
* Se houver mais de uma classe filha requisitando banda adicional, a classe mãe divide essa banda proporcionalmente à taxa garantida de cada filha.
−
* Em ''pc'' executa-se o ''siprtp'' em modo cliente, de forma a efetuar uma chamada para ''server2'': <syntaxhighlight lang=bash>
+
* Classes podem ter prioridades, de forma que classes mais prioritárias se apropriam primeiro da banda de sobra (mas a taxa garantida é preservada).
−
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>
+
Os parâmetros da qdisc HTB estão sumarizados abaixo:
−
>>> 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''.
 
  
−
3) 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'':
+
{| border="1" cellpadding="2"
−
* Crie um arquivo de 16 MB em ''server1'': <syntaxhighlight lang=bash>
+
!Parâmetro
−
dd if=/dev/urandom of=/var/www/teste.img bs=4096 count=4096
+
!Descrição
−
</syntaxhighlight>
+
!Exemplo
−
* Inicie seu download em ''pc'': <syntaxhighlight lang=bash>
+
|-
−
wget http://192.168.1.1/teste.img > log 2>&1 &
+
| rate || taxa garantida || rate 100kbit
−
</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.
+
|ceil || taxa máxima || ceil 200 kbit
−
 
+
|-
−
4) 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:
+
  |prio || prioridade da classe (menores valores = maiores prioridades) || prio 1
−
* Em ''r1'' e ''r2'' cria-se uma qdisc do tipo ''prio'' na interface ''eth1''. 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 ''/root/qdisc.sh'':<syntaxhighlight lang=bash>
+
  |-
−
#!/bin/bash
+
  |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
−
   
+
|-
−
# Limpa as qdisc que porventura existam
+
  |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
−
tc qdisc del dev eth1 root
+
  |}
−
   
+
 
−
# Cria uma qdisc HTB (Hierarchical Token Bucket) para limitar a saída a uma taxa comparável
+
=== Atividade ===
−
# 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
 
  
−
</syntaxhighlight>... e em seguida execute-o: <syntaxhighlight lang=bash>
+
A rede abaixo será usada para os experimentos com ''disciplinas de enfileiramento'':
−
bash /root/qdisc.sh
 
−
</syntaxhighlight>
 
−
* Repita o ítem 2, e observe as perdas de pacotes e ''jitter'' da chamada VoIP. Houve melhora ?
 
  
−
5) 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>
 
  
−
6) E se for desejável limitar o atendimento com qualidade de até quatro chamadas, deixando o restante da capacidade do link para transferências de dados ? Pense numa forma de fazer isso usando as disciplinas de filas do Linux (''dica: veja a qdisc TBF'').
+
[[imagem:Rede-qos-rtp2.png|680px]]
−
* Implemente essa limitação nos roteadores.
 
−
* Teste qual a taxa disponível para transferências de dados.
 
−
* verifique se até quatro chamadas simultâneas podem ser atendidas a contento.
 
  
−
<!--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>
+
{{collapse top | Configuração para o Netkit (salvar em Lab.conf)}}
−
# Cria uma qdisc PRIO, que usa três filas (bandas) para priorizar fluxos.
+
<syntaxhighlight lang=text>
−
# -- a fila mais prioritária tem handle 1:1
+
# Global attributes: these values are obtained automatically from menu General->Preferences
−
# -- a próxima fila tem handle 1:2
+
# 32 MB por VM
−
# -- a fila menos prioritária tem handle 1:3
+
global[mem]=32
−
# OBS: assume-se que a interface de saída seja eth0
+
# Não remove o diretório de trabalho ao final da execução
−
tc qdisc add dev eth0 root handle 1:0 prio
+
global[clean]=False
−
 
+
−
# Datagramas vindos da rede 172.18.0.0/16 vão pra fila mais prioritária.
+
server1[type]=generic
−
tc filter add dev eth0 parent 1: prio 1 protocol ip u32 match ip src 172.18.0.0/16 flowid 1:1
+
server2[type]=generic
−
 
+
pc1[type]=generic
−
# Demais datagramas vão para a fila intermediária.
+
pc2[type]=generic
−
tc filter add dev eth0 parent 1: prio 2 protocol ip u32 match ip src 0.0.0.0/0 flowid 1:2
+
pc3[type]=generic
−
</syntaxhighlight>
+
r1[type]=gateway
−
 
+
r2[type]=gateway
−
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.
+
# Rede 1: servidores + roteador r1
−
# -- a fila mais prioritária tem handle 1:1
+
server1[eth0]=rede1:ip=192.168.1.1/24
−
# -- a próxima fila tem handle 1:2
+
server2[eth0]=rede1:ip=192.168.1.2/24
−
# -- a fila menos prioritária tem handle 1:3
+
r1[eth0]=rede1:ip=192.168.1.254/24
−
# OBS: assume-se que a interface de saída seja eth0
+
−
tc qdisc add dev eth0 root handle 1:0 prio
+
# 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
  
−
# Balanceia os fluxos nas duas filas da qdisc PRIO que serão usadas
+
</syntaxhighlight>
−
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.
+
{{collapse bottom}}
−
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.
+
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.
−
tc filter add dev eth0 parent 1: prio 2 protocol ip u32 match ip src 0.0.0.0/0 flowid 1:2
+
* 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'').
−
</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.
+
{{collapse top|Regras para criar as disciplinas de filas}}
 +
<syntaxhighlight lang=bash>
 +
#!/bin/bash
  
−
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.
+
IFACE=eth1
−
-->
 
  
−
<!-- == TAREFA: leitura da semana ==
+
tc qdisc del dev $IFACE root > /dev/null 2>&1
  
−
O texto a seguir continua a leitura desta semana, tratando da implantação de uma estrutura Diffserv na borda da rede.
+
# adiciona a qdisc raiz na interface eth0
−
* [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)'']
+
tc qdisc add dev $IFACE root handle 1:0 htb default 22
−
-->
 
  
−
= 25/10: QoS em um roteador Linux (cont.) =
+
# 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
  
−
Conclusão da atividade da aula anterior.
+
# 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
  
−
= 30/10: QoS em roteador Linux =
+
# 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
 +
</syntaxhighlight>
 +
{{collapse bottom}}
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-13.pdf Transparências]
+
2) Modifique as regras de QoS do exercicio 1 de forma que:
−
* [http://opalsoft.net/qos/DS.htm Um bom tutorial sobre disciplinas de filas no Linux]
+
* pc1 tenha garantidos 256 kbps, com garantia de QoS para uma chamada VoIP.
−
* [http://lartc.org/howto/ Linux Advanced Routing and Traffic Control Howto:] quase tudo sobre disciplinas de filas (e mais outras coisas).
+
* pc2 tenha garantidos 256 kbps, com garantia de QoS para duas chamadas VoIP.
−
* [http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm HTB (Hierarchical Token Bucket) queuing discipline ]
+
* pc3 não tenha banda garantida, mas possa usar a banda ociosa.
  
−
== ''qdisc'' com estado (''stateful'') ==
+
Exemplo de como criar um classificador baseado em endereços IP: <syntaxhighlight lang=bash>
  
−
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.
+
# classifica de acordo com o endereço IP de destino do datagrama
 +
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 4.3.2.1/32 flowid 1:22
  
−
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
 
  
 +
# classifica de acordo com o endereço IP de origem do datagrama
 +
tc filter add dev eth1 protocol ip parent 1:0 prio 2 u32 match ip src 4.3.2.1/32 flowid 1:22
  
−
O diagrama abaixo mostra como poderia ser modelada a limitação de banda para essas aplicações:
+
# classifica de acordo com o endereço IP de origem do datagrama E se for UDP
 +
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32
 +
match ip protocol 17 0xff flowid 1:22
  
 +
# classifica de acordo com o endereço IP de origem do datagrama E port de origem 80
 +
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32
 +
match ip sport 80 0xffff flowid 1:22
  
−
[[imagem:Qdisc-ex1.png]]
+
# classifica de acordo com o endereço IP de origem do datagrama E port de destino 80
−
 
+
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32
−
 
+
match ip dport 80 0xffff flowid 1:22
−
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:
+
</syntaxhighlight>
−
 
 
−
 
 
−
[[imagem:Qdisc-ex1-diagram.png]]
 
−
 
 
  
 +
{{collapse top | Regras para o r2}}
 
<syntaxhighlight lang=bash>
 
<syntaxhighlight lang=bash>
 +
#!/bin/bash
 +
 +
IFACE=eth1
 +
 +
tc qdisc del dev $IFACE root > /dev/null 2>&1
 +
 
# adiciona a qdisc raiz na interface eth0
 
# adiciona a qdisc raiz na interface eth0
−
tc qdisc add dev eth0 root handle 1:0 htb default 23
+
tc qdisc add dev $IFACE root handle 1:0 htb default 23
−
 
+
 
# cria a classe filha, que impõe o limite de banda global desta HTB
 
# 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
+
tc class add dev $IFACE parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit
 +
 +
# cria as classes das aplicações
  
−
# cria as classes das aplicações
+
# Regras para pc1
−
tc class add dev eth0 parent 1:1 classid 1:21 htb rate 40kbps ceil 100kbps
+
tc class add dev $IFACE parent 1:1 classid 1:21 htb rate 256kbit ceil 512kbit
−
tc class add dev eth0 parent 1:1 classid 1:22 htb rate 40kbps ceil 100kbps
+
tc class add dev $IFACE parent 1:21 classid 1:31 htb prio 1 rate 90kbit ceil 90kbit
−
tc class add dev eth0 parent 1:1 classid 1:23 htb rate 20kbps ceil 100kbps
+
tc class add dev $IFACE parent 1:21 classid 1:32 htb prio 2 rate 166kbit ceil 512kbit
 +
 
 +
# Regras para pc2
 +
tc class add dev $IFACE parent 1:1 classid 1:22 htb rate 256kbit ceil 512kbit
 +
tc class add dev $IFACE parent 1:21 classid 1:33 htb prio 1 rate 180kbit ceil 180kbit
 +
tc class add dev $IFACE parent 1:21 classid 1:34 htb prio 2 rate 76kbit ceil 512kbit
  
 +
# Regras para pc3
 +
tc class add dev $IFACE parent 1:1 classid 1:23 htb rate 1bps ceil 512kbit
 +
 
# cria os filtros para classificar os datagramas
 
# 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 $IFACE protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff match ip src 192.168.2.1/32 flowid 1:31
−
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
+
tc filter add dev $IFACE protocol ip parent 1:0 prio 2 u32 match ip src 192.168.2.1/32 flowid 1:32
 +
 
 +
tc filter add dev $IFACE protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff match ip src 192.168.2.2/32 flowid 1:33
 +
 
 +
tc filter add dev $IFACE protocol ip parent 1:0 prio 2 u32 match ip src 192.168.2.2/32 flowid 1:34
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
{{collapse bottom}}
  
−
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).
 
  
 +
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.
  
−
Os parâmetros da qdisc HTB estão sumarizados abaixo:
+
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.
  
−
{| border="1" cellpadding="2"
+
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 ?
−
!Parâmetro
+
* 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 ?
−
!Descrição
+
* Como se poderia resolver o exercício 2 caso se usasse WFQ ?
−
!Exemplo
+
* '''DESAFIO:''' faça um programa ou script que implante uma disciplina WFQ no Linux.
−
|-
+
 
−
| rate || taxa garantida || rate 100kbit
+
<!-- == Classificação com iptables ==
−
|-
+
 
−
|ceil || taxa máxima || ceil 200 kbit
+
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.
−
|-
+
 
−
|prio || prioridade da classe (menores valores = maiores prioridades) || prio 1
+
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>
−
|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
+
# coloca pacotes do SSH na classe 1:21
−
|-
+
iptables -t mangle -A POSTROUTING -p tcp --dport 22 -j CLASSIFY --set-class 1:21
−
|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
+
</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
 +
iptables -t mangle -A FORWARD -i eth0 -p tcp --dport 22 -j MARK --set-mark 2
 +
</syntaxhighlight>
  
 
=== Atividade ===
 
=== Atividade ===
  
−
A rede abaixo será usada para os experimentos com ''disciplinas de enfileiramento'':
+
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)
 +
-->
  
 +
== Exercícios ==
  
−
[[imagem:Rede-qos-rtp2.png|680px]]
+
Sobre disciplinas de filas e QoS.
  
 +
'''Lista:''' exercícios 20 a 28 do cap. 7 do livro ''Redes de Computadores e a Internet, 5a edição'', de James Kurose.
 +
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/prova-filas-demo.pdf Questões de avaliações anteriores]
 +
 +
= 01/11: continuação dos exercícios =
 +
 +
Uma forma alternativa de classificar pacotes para as qdisc:
 +
 +
* '''Usando o ''iptables'':''' na tabela ''mangle'' usa-se o alvo CLASSIFY para associar um datagrama a uma classe. 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
 +
 +
# datagramas da classe DSCP AF41 vão para a classe 1:21 do tc
 +
iptables -t mangle -A FORWARD -p tcp --sport 80 -j CLASSIFY --set-class 1:12
 +
iptables -t mangle -A FORWARD -p tcp --sport 443 -j CLASSIFY --set-class 1:12
 +
</syntaxhighlight>
 +
 +
=== Dicas para o iptables ===
 +
 +
Uma regra com [https://help.ubuntu.com/community/IptablesHowTo iptables] deve especificar basicamente quatro coisas:
 +
* '''Tabela:''' a tabela indica a finalidade da regra. No caso do classificador, deve ser ''mangle''. Essa tabela contém regras que modificam valores de cabeçalhos de pacotes (no caso, a classe/qdisc).
 +
* '''Chain''': em que ''chain'' deve ser adicionada.
 +
** No caso do classificador, deve-se usar a chain FORWARD (avalia as regras logo após consultar a tabela de rotas).
 +
* '''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.
 +
** Dependendo do ''alvo'' pode haver opções adicionais .
  
−
{{collapse top | Configuração para o Netkit (salvar em Lab.conf)}}
 
−
<syntaxhighlight lang=text>
 
−
# 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
 
  
−
</syntaxhighlight>
+
Por exemplo, a regra abaixo marca com o [http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0/qos/configuration/guide/qos_6dscp_val.pdf DSCP] AF41 os datagramas vindos da rede 172.18.0.0/16:
  
−
{{collapse bottom}}
 
  
−
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.
+
[[imagem:Iptables-diffserv.png]]
−
* 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'').
 
−
 
 
−
{{collapse top|Regras para criar as disciplinas de filas}}
 
−
<syntaxhighlight lang=bash>
 
−
#!/bin/bash
 
  
−
IFACE=eth1
 
  
−
tc qdisc del dev $IFACE root > /dev/null 2>&1
+
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].
  
−
# adiciona a qdisc raiz na interface eth0
+
{| border="1" cellpadding="2"
−
tc qdisc add dev $IFACE root handle 1:0 htb default 22
+
!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:<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
 +
|}
  
−
# cria a classe filha, que impõe o limite de banda global desta HTB
+
= 06/11: Diffserv em roteador Linux =
−
tc class add dev $IFACE parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit
 
  
−
# cria as classes das aplicações
+
* [http://datatracker.ietf.org/wg/diffserv/charter/ Página do Grupo de Trabalho DiffServ no IETF]
−
tc class add dev $IFACE parent 1:1 classid 1:21 htb rate 180kbit ceil 512kbit
+
* [http://datatracker.ietf.org/doc/rfc2475/ RFC 2475: Definição da Arquitetura DiffServ]
−
tc class add dev $IFACE parent 1:1 classid 1:22 htb rate 1bps ceil 512kbit
+
* [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)]
  
−
# cria os filtros para classificar os datagramas
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-06.pdf Transparências]
−
tc filter add dev $IFACE protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff flowid 1:21
 
−
</syntaxhighlight>
 
−
{{collapse bottom}}
 
  
−
2) Modifique as regras de QoS do exercicio 1 de forma que:
+
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.
−
* pc1 tenha garantidos 256 kbps, com garantia de QoS para uma chamada VoIP.
+
* '''Flexibilidade:''' o tratamento de cada classe de tráfego é uma decisão da gerência da rede, e assim não é especificada na proposta.
−
* pc2 tenha garantidos 256 kbps, com garantia de QoS para duas chamadas VoIP.
+
* '''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.
−
* pc3 não tenha banda garantida, mas possa usar a banda ociosa.
 
  
−
Exemplo de como criar um classificador baseado em endereços IP: <syntaxhighlight lang=bash>
+
''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]''
  
−
# classifica de acordo com o endereço IP de destino do datagrama
 
−
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 4.3.2.1/32 flowid 1:22
 
  
 +
Uma visão geral da arquitetura DiffServ pode ser vista na figura abaixo:
  
−
# classifica de acordo com o endereço IP de origem do datagrama
 
−
tc filter add dev eth1 protocol ip parent 1:0 prio 2 u32 match ip src 4.3.2.1/32 flowid 1:22
 
  
−
# classifica de acordo com o endereço IP de origem do datagrama E se for UDP
+
[[imagem:Diffserv-arch.png]]
−
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32
+
<br>''Arquitetura DiffServ''
−
match ip protocol 17 0xff flowid 1:22
 
  
−
# classifica de acordo com o endereço IP de origem do datagrama E port de origem 80
 
−
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32
 
−
match ip sport 80 0xffff flowid 1:22
 
  
−
# classifica de acordo com o endereço IP de origem do datagrama E port de destino 80
+
Diversos elementos compõem a arquitetura:
−
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32
+
* '''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.
−
match ip dport 80 0xffff flowid 1:22
+
* '''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.
−
</syntaxhighlight>
+
* '''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.
  
−
{{collapse top | Regras para o r2}}
 
−
<syntaxhighlight lang=bash>
 
−
#!/bin/bash
 
−
 
−
IFACE=eth1
 
−
 
−
tc qdisc del dev $IFACE root > /dev/null 2>&1
 
−
 
−
# adiciona a qdisc raiz na interface eth0
 
−
tc qdisc add dev $IFACE 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 $IFACE parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit
 
−
 
−
# cria as classes das aplicações
 
  
−
# Regras para pc1
+
[[imagem:Diffserv-tcb.png]]
−
tc class add dev $IFACE parent 1:1 classid 1:21 htb rate 256kbit ceil 512kbit
+
<br>''PHB - Per-Hop Behaviour''
−
tc class add dev $IFACE parent 1:21 classid 1:31 htb prio 1 rate 90kbit ceil 90kbit
 
−
tc class add dev $IFACE parent 1:21 classid 1:32 htb prio 2 rate 166kbit ceil 512kbit
 
  
−
# Regras para pc2
 
−
tc class add dev $IFACE parent 1:1 classid 1:22 htb rate 256kbit ceil 512kbit
 
−
tc class add dev $IFACE parent 1:21 classid 1:33 htb prio 1 rate 180kbit ceil 180kbit
 
−
tc class add dev $IFACE parent 1:21 classid 1:34 htb prio 2 rate 76kbit ceil 512kbit
 
  
−
# Regras para pc3
+
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:
−
tc class add dev $IFACE parent 1:1 classid 1:23 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 match ip src 192.168.2.1/32 flowid 1:31
 
  
−
tc filter add dev $IFACE protocol ip parent 1:0 prio 2 u32 match ip src 192.168.2.1/32 flowid 1:32
+
{| border="0" cellpadding="2"
 +
|-
 +
|[[imagem:Ip-tos.png|400px]] ||[[imagem:Dscp.png|400px]]
 +
|}
  
−
tc filter add dev $IFACE protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff match ip src 192.168.2.2/32 flowid 1:33
 
  
−
tc filter add dev $IFACE protocol ip parent 1:0 prio 2 u32 match ip src 192.168.2.2/32 flowid 1:34
+
<!-- [[imagem:Ip-headers.png]] -->
−
</syntaxhighlight>
 
−
{{collapse bottom}}
 
  
 +
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 [http://www.ietf.org/rfc/rfc2474.txt 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 [http://www.ietf.org/rfc/rfc2474.txt 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 101110 (ver [http://www.ietf.org/rfc/rfc2598.txt 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.
  
−
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.
+
[[imagem:Aff-codepoint-table.png]]
 +
<br>''Classes de serviço e precedências de descarte em AF PHB''
  
−
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 ?
+
== Uma interpretação sobre Diffserv ==
−
* 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 ?
 
−
* '''DESAFIO:''' faça um programa ou script que implante uma disciplina WFQ no Linux.
 
  
−
<!-- == Classificação com iptables ==
+
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:
  
−
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.  
+
* '''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.
  
−
Para fins de classificação, deve-se usar a tabela ''mangle''. Além disso, o uso do ''iptables'' pode ser feito de duas formas:
+
Traffic MUST be policed and/or shaped at the source edge (for
−
# '''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>
+
example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in
−
# coloca pacotes do SSH na classe 1:21
+
order to get such a bound. However, specific policing and/or shaping
−
iptables -t mangle -A POSTROUTING -p tcp --dport 22 -j CLASSIFY --set-class 1:21
+
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>
 
</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>
+
* '''Encaminhamento Assegurado (Assured Forwarding - AF):''' oferece diferentes probabilidades de que pacotes sejam encaminhados.
−
# filtro do tc que classifica de acordo com a marcação: pacotes com marca "2" são colocados na classe 1:21
+
** ''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.
−
tc filter add dev eth0 parent 1:0 protocol ip handle 2 fw flowid 1:21
+
** ''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
−
# iptables marca o pacote
+
depends on (1) how much forwarding resources has been allocated to
−
iptables -t mangle -A FORWARD -i eth0 -p tcp --dport 22 -j MARK --set-mark 2
+
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>
 
</syntaxhighlight>
  
−
=== Atividade ===
+
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.
  
−
Modifique as regras criadas nos [[RMU-2012-1#Atividade_8|exercícios anteriores]] para que usem:
+
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:
−
# iptables para classificação direta (alvo CLASSIFY)
+
* Como policiar tráfego que entra em um domínio DiffServ ?
−
# iptables para marcar pacotes (alvo MARK)
+
* 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 ?
  
−
== Exercícios ==
+
== Marcação DiffServ ==
  
−
Sobre disciplinas de filas e QoS.
+
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
  
−
'''Lista:''' exercícios 20 a 28 do cap. 7 do livro ''Redes de Computadores e a Internet, 5a edição'', de James Kurose.
+
# 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
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/prova-filas-demo.pdf Questões de avaliações anteriores]
+
</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
  
−
= 01/11: continuação dos exercícios =
+
# 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
 +
</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
  
−
= 06/11: Diffserv em roteador Linux =
+
# 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
  
−
* [http://datatracker.ietf.org/wg/diffserv/charter/ Página do Grupo de Trabalho DiffServ no IETF]
+
# datagramas da classe DSCP AF41 vão para a classe 1:21 do tc
−
* [http://datatracker.ietf.org/doc/rfc2475/ RFC 2475: Definição da Arquitetura DiffServ]
+
iptables -t mangle -A FORWARD -m dscp --dscp-class af41 -j CLASSIFY --set-class 1:12
−
* [http://datatracker.ietf.org/doc/rfc3246/?include_text=1 RFC 3246: Comportamento de um PHB Expedited Forwarding (EF)]
+
</syntaxhighlight>
−
* [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)]
 
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-06.pdf Transparências]
+
=== Dicas para o iptables ===
  
−
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.
+
Uma regra com [https://help.ubuntu.com/community/IptablesHowTo iptables] deve especificar basicamente quatro coisas:
−
* '''Flexibilidade:''' o tratamento de cada classe de tráfego é uma decisão da gerência da rede, e assim não é especificada na proposta.
+
* '''Tabela:''' a tabela indica a finalidade da regra. No caso do classificador/marcador e também do PHB, deve ser ''mangle''. Essa tabela contém regras que modificam valoers de cabeçalhos de pacotes (no caso, o DSCP).
−
* '''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.
+
* '''Chain''': em que ''chain'' deve ser adicionada.
 +
** No caso do classificador/marcador, deve-se usar a chain PREROUTING (avalia os pacotes antes de serem roteados).
 +
** No caso do PHB, deve-se usar a chain FORWARD (avalia as regras logo após consultar a tabela de rotas).
 +
* '''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.
 +
** Dependendo do ''alvo'' pode haver opções adicionais .
  
−
''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]''
 
  
 +
Por exemplo, a regra abaixo marca com o DSCP AF41 os datagramas vindos da rede 172.18.0.0/16:
  
−
Uma visão geral da arquitetura DiffServ pode ser vista na figura abaixo:
 
  
 +
[[imagem:Iptables-diffserv.png]]
  
−
[[imagem:Diffserv-arch.png]]
 
−
<br>''Arquitetura DiffServ''
 
  
 +
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].
  
−
Diversos elementos compõem a arquitetura:
+
{| border="1" cellpadding="2"
−
* '''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.
+
!Opção
−
* '''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.
+
!Descrição
−
* '''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.
+
!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:<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
 +
|}
  
−
[[imagem:Diffserv-tcb.png]]
+
== Policiamento de tráfego ==
−
<br>''PHB - Per-Hop Behaviour''
+
 
 +
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.
  
 +
'''''Exemplo:'''''
 +
<syntaxhighlight lang=bash>
 +
# Cria a qdisc ingress
 +
tc qdisc add dev eth0 ingress
  
−
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:
+
# 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>
  
−
{| border="0" cellpadding="2"
+
== Atividade ==
−
|-
 
−
|[[imagem:Ip-tos.png|400px]] ||[[imagem:Dscp.png|400px]]
 
−
|}
 
  
 +
Um pequeno provedor possui uma rede como mostrado abaixo. Essa rede é usada para interligar seus clientes, no caso as empresas Ajax e Tabajara.
  
−
<!-- [[imagem:Ip-headers.png]] -->
 
  
−
Os comportamentos por salto podem ser:
+
[[imagem:Diffserv-rede1.png]]
−
* '''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].
 
−
* '''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]
 
−
* '''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]
 
−
* '''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.
 
  
 +
{{collapse top|Configuração para o Netkit}}
 +
<syntaxhighlight lang=text>
 +
B1[type]=gateway
 +
B2[type]=gateway
 +
N1[type]=gateway
 +
Ajax1[type]=generic
 +
Ajax2[type]=generic
 +
Tabajara1[type]=generic
 +
Tabajara2[type]=generic
  
−
[[imagem:Aff-codepoint-table.png]]
+
# Preservando o script que cria as regras de QoS nos roteadores.
−
<br>''Classes de serviço e precedências de descarte em AF PHB''
+
# 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
  
−
== Uma interpretação sobre Diffserv ==
+
# 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
  
−
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:
+
N1[eth0]=link3:ip=10.0.0.2/28
 +
N1[eth1]=link4:ip=10.0.0.18/28
  
−
* '''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].
+
B2[eth0]=link5:ip=192.168.1.254/24
−
** ''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.
+
B2[eth1]=link6:ip=192.168.11.254/24
−
** ''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>
+
B2[eth2]=link4:ip=10.0.0.17/28
−
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
+
Ajax1[eth0]=link1:ip=192.168.0.1/24
−
example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in
+
Ajax2[eth0]=link5:ip=192.168.1.1/24
−
order to get such a bound. However, specific policing and/or shaping
+
 
−
rules are outside the scope of the DB PHB definition. Such rules
+
Tabajara1[eth0]=link2:ip=192.168.10.1/24
−
MUST be defined in any per-domain behaviors (PDBs) composed from the
+
Tabajara2[eth0]=link6:ip=192.168.11.1/24
−
DB PHB.
+
 
−
</syntaxhighlight>
+
# Rotas ...
−
* '''Encaminhamento Assegurado (Assured Forwarding - AF):''' oferece diferentes probabilidades de que pacotes sejam encaminhados.
+
Ajax1[default_gateway]=192.168.0.254
−
** ''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.
+
Ajax2[default_gateway]=192.168.1.254
−
** ''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>
+
Tabajara1[default_gateway]=192.168.10.254
−
In a DS node, the level of forwarding assurance of an IP packet thus
+
Tabajara2[default_gateway]=192.168.11.254
−
depends on (1) how much forwarding resources has been allocated to
+
B1[default_gateway]=10.0.0.2
−
the AF class that the packet belongs to, (2) what is the current load
+
B2[default_gateway]=10.0.0.18
−
of the AF class, and, in case of congestion within the class, (3)
+
N1[route]=192.168.0.0/24:gateway=10.0.0.1
−
what is the drop precedence of the packet.
+
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}}
 +
 +
Para implantar a estrutura DiffServ, deve-se começar com o seguinte:
  
−
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.
+
'''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.
  
−
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:
+
'''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.
−
* 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 ==
+
'''''OBS:''''' os links dentro da rede do provedor estão superdimensionados, portanto não apresentam gargalos.
 +
<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''.
  
−
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:
+
Tendo a estrutura inicial preparada, resolva os seguintes problemas:
−
# '''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
 
−
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>
+
'''1)''' O cliente Ajax contratou um link de 1256 kbps, e Tabajara contratou um link de 512 kbps. 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).
−
# 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
+
'''PARA TESTAR:'''
−
tc qdisc add dev eth0 parent 1:0 handle 2:0 htb default 13
+
* Verifique se os pacotes estãop devidamente marcados (isso pode ser feito em N1 usando ''tcpdump'' ou ''wireshark'')
−
tc class add dev eth0 parent 2:0 classid 2:1 htb rate 100kbps ceil 100kbps
+
* Teste se a vazão esperada para dados está sendo obtida. Use o ''netperf'': <syntaxhighlight lang=bash>
−
tc class add dev eth0 parent 2:1 classid 2:12 htb rate 80kbps ceil 100kbps
+
netperf -f k -H IP_do_outro_computador
−
tc class add dev eth0 parent 2:1 classid 2:13 htb rate 20kbps ceil 100kbps
+
</syntaxhighlight>
 +
* Teste também chamadas VoIP usando o [[RMU-2013-1#Como_testar_chamadas_no_Netkit|siprtp]].
  
−
# 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
 
  
−
# marca os datagramas vindos da rede 172.18.0.0/16 na classe AF41
+
'''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 PCMU, e que pode haver até 5 streams simultâneas, use a sua estrutura DiffServ para atender essa necessidade.
−
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
+
{{collapse top|Uma possível solução (aproximada) para B1 e B2}}
−
</syntaxhighlight>
+
<syntaxhighlight lang=bash>
 +
#!/bin/bash
  
−
=== Dicas para o iptables ===
+
IFACE=eth2
  
−
Uma regra com [https://help.ubuntu.com/community/IptablesHowTo iptables] deve especificar basicamente quatro coisas:
+
tc qdisc del dev $IFACE root
−
* '''Tabela:''' a tabela indica a finalidade da regra. No caso do classificador/marcador e também do PHB, deve ser ''mangle''. Essa tabela contém regras que modificam valoers de cabeçalhos de pacotes (no caso, o DSCP).
 
−
* '''Chain''': em que ''chain'' deve ser adicionada.
 
−
** No caso do classificador/marcador, deve-se usar a chain PREROUTING (avalia os pacotes antes de serem roteados).
 
−
** No caso do PHB, deve-se usar a chain FORWARD (avalia as regras logo após consultar a tabela de rotas).
 
−
* '''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.
 
−
** Dependendo do ''alvo'' pode haver opções adicionais .
 
  
 +
# adiciona a qdisc raiz na interface eth0
 +
tc qdisc add dev $IFACE 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 $IFACE parent 1:0 classid 1:1 htb rate 4000kbit ceil 4000kbit
 +
 +
# cria as classes das aplicações
 +
#AJAX
 +
tc class add dev $IFACE parent 1:1 classid 1:21 htb prio 2 rate 1256kbit ceil 1256kbit
 +
# AJAX: EF
 +
tc class add dev $IFACE parent 1:21 classid 1:31 htb prio 1 rate 450kbit ceil 1256kbit
 +
# AJAX: AF
 +
tc class add dev $IFACE parent 1:21 classid 1:32 htb prio 2 rate 806kbit ceil 1256kbit
 +
# TABAJARA
 +
tc class add dev $IFACE parent 1:1 classid 1:22 htb prio 2 rate 512kbit ceil 512kbit
 +
# Outras (melhor esforço) ???
 +
tc class add dev $IFACE parent 1:1 classid 1:23 htb prio 3 rate 1bps ceil 512kbit
 +
 +
# marca os datagramas vindos de Ajax classes AF41 e EF
 +
# UDP (VoIP) são EF
 +
iptables -t mangle -A PREROUTING -i eth0 -p udp -j DSCP --set-dscp-class ef
 +
# Ajax: dados em geral são AF41
 +
iptables -t mangle -A PREROUTING -i eth0 -j DSCP --set-dscp-class af41
  
−
Por exemplo, a regra abaixo marca com o DSCP AF41 os datagramas vindos da rede 172.18.0.0/16:
+
# Tabajara: no momento somente AF31
−
 
+
iptables -t mangle -A PREROUTING -i eth1 -j DSCP --set-dscp-class af31
−
 
 
−
[[imagem:Iptables-diffserv.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 [http://manpages.ubuntu.com/manpages/natty/man8/iptables.8.html manual].
 
−
 
 
−
{| border="1" cellpadding="2"
 
−
!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:<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
 
−
|}
 
−
 
 
−
== 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.
+
# datagramas da classe DSCP AF41 vão para a fila 1:21
 +
iptables -t mangle -A FORWARD -m dscp --dscp-class af41 -j CLASSIFY --set-class 1:32
 +
# ... e da classe EF vão para 1:41
 +
iptables -t mangle -A FORWARD -i eth0 -m dscp --dscp-class ef -j CLASSIFY --set-class 1:31
  
−
'''''Exemplo:'''''
+
# datagramas da classe DSCP AF41 vão para a fila 1:22
 +
iptables -t mangle -A FORWARD -m dscp --dscp-class af31 -j CLASSIFY --set-class 1:22
 +
</syntaxhighlight>
 +
{{collapse bottom}}
 +
{{collapse top|Uma possível solução (aproximada) para N1}}
 
<syntaxhighlight lang=bash>
 
<syntaxhighlight lang=bash>
−
# Cria a qdisc ingress
+
#!/bin/bash
−
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.
+
for IFACE in eth0 eth1; do
−
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>
 
  
−
== Atividade ==
+
  tc qdisc del dev $IFACE root
  
−
Um pequeno provedor possui uma rede como mostrado abaixo. Essa rede é usada para interligar seus clientes, no caso as empresas Ajax e Tabajara.
+
  # adiciona a qdisc raiz na interface eth0
 +
  tc qdisc add dev $IFACE root handle 1:0 htb default 1
 +
 +
  # 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 4000kbit ceil 4000kbit
 +
 +
  # cria as classes das aplicações
 +
  tc qdisc add dev $IFACE parent 1:1 handle 2:0 prio
 +
 +
  # datagramas da classe DSCP EF vão para a fila 2:1
 +
  iptables -t mangle -A FORWARD -m dscp --dscp-class ef -j CLASSIFY --set-class 2:1
  
 +
  # datagramas das classe DSCP AFXX vão para a fila 2:2
 +
  iptables -t mangle -A FORWARD -m dscp --dscp-class af41 -j CLASSIFY --set-class 2:2
 +
  iptables -t mangle -A FORWARD -m dscp --dscp-class af31 -j CLASSIFY --set-class 2:2
  
−
[[imagem:Diffserv-rede1.png]]
+
  # demais datagramas (DSCP BE) vão para a fila 2:3
 +
  iptables -t mangle -A FORWARD -j CLASSIFY --set-class 2:3
  
−
{{collapse top|Configuração para o Netkit}}
+
done
−
<syntaxhighlight lang=text>
+
</syntaxhighlight>
−
B1[type]=gateway
+
{{collapse bottom}}
 +
-->
 +
'''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 GSM, e a stream de video use 256 kbps, use a estrutura DiffServ para atender essa demanda.
 +
 
 +
 
 +
'''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 [http://www.opalsoft.net/qos/DS-27.htm GRED]).
 +
 
 +
= 08/11: DiffServ em roteador Linux (continuação) =
 +
 
 +
<!-- Para concluir o estudo sobre Diffserv, será feito um projeto com esta outra rede:
 +
 
 +
[[imagem:Diffserv-rede2.png]]
 +
 
 +
 
 +
{{collapse top|Configuração para o Netkit}}
 +
<syntaxhighlight lang=text>
 +
B1[type]=gateway
 
B2[type]=gateway
 
B2[type]=gateway
 +
B3[type]=gateway
 +
B4[type]=gateway
 
N1[type]=gateway
 
N1[type]=gateway
 
Ajax1[type]=generic
 
Ajax1[type]=generic
Linha 2 905: Linha 3 115:
 
Tabajara1[type]=generic
 
Tabajara1[type]=generic
 
Tabajara2[type]=generic
 
Tabajara2[type]=generic
−
 
+
Lexcorp1[type]=generic
 +
Lexcorp2[type]=generic
 +
 
# Preservando o script que cria as regras de QoS nos roteadores.
 
# 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 ...
 
# 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
 
B1[preserve]=/root/firewall.sh
 
B2[preserve]=/root/firewall.sh
 
B2[preserve]=/root/firewall.sh
 +
B3[preserve]=/root/firewall.sh
 +
B4[preserve]=/root/firewall.sh
 
N1[preserve]=/root/firewall.sh
 
N1[preserve]=/root/firewall.sh
−
 
+
 
# Links ...
 
# Links ...
−
B1[eth0]=link1:ip=192.168.0.254/24
+
B1[eth0]=link-ajax1:ip=192.168.1.254/24
−
B1[eth1]=link2:ip=192.168.10.254/24
+
B1[eth1]=link-n1-b1:ip=10.0.0.1/30
−
B1[eth2]=link3:ip=10.0.0.1/28
+
B2[eth0]=link-tab2:ip=192.168.12.254/24
−
 
+
B2[eth1]=link-lex1:ip=192.168.21.254/24
−
N1[eth0]=link3:ip=10.0.0.2/28
+
B2[eth2]=link-n1-b2:ip=10.0.0.5/30
−
N1[eth1]=link4:ip=10.0.0.18/28
+
B3[eth0]=link-tab1:ip=192.168.11.254/24
−
 
+
B3[eth1]=link-n1-b3:ip=10.0.0.9/30
−
B2[eth0]=link5:ip=192.168.1.254/24
+
B4[eth0]=link-ajax2:ip=192.168.2.254/24
−
B2[eth1]=link6:ip=192.168.11.254/24
+
B4[eth1]=link-lex2:ip=192.168.22.254/24
−
B2[eth2]=link4:ip=10.0.0.17/28
+
B4[eth2]=link-n1-b4:ip=10.0.0.13/30
−
 
+
−
Ajax1[eth0]=link1:ip=192.168.0.1/24
+
N1[eth0]=link-n1-b1:ip=10.0.0.2/30
−
Ajax2[eth0]=link5:ip=192.168.1.1/24
+
N1[eth1]=link-n1-b2:ip=10.0.0.6/30
−
 
+
N1[eth2]=link-n1-b3:ip=10.0.0.10/30
−
Tabajara1[eth0]=link2:ip=192.168.10.1/24
+
N1[eth3]=link-n1-b4:ip=10.0.0.14/30
−
Tabajara2[eth0]=link6:ip=192.168.11.1/24
+
−
 
+
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 ...
 
# Rotas ...
−
Ajax1[default_gateway]=192.168.0.254
+
Ajax1[default_gateway]=192.168.1.254
−
Ajax2[default_gateway]=192.168.1.254
+
Ajax2[default_gateway]=192.168.2.254
−
Tabajara1[default_gateway]=192.168.10.254
+
Tabajara1[default_gateway]=192.168.11.254
−
Tabajara2[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
 
B1[default_gateway]=10.0.0.2
−
B2[default_gateway]=10.0.0.18
+
B2[default_gateway]=10.0.0.6
−
N1[route]=192.168.0.0/24:gateway=10.0.0.1
+
B3[default_gateway]=10.0.0.10
−
N1[route]=192.168.10.0/24:gateway=10.0.0.1
+
B4[default_gateway]=10.0.0.14
−
N1[route]=192.168.1.0/24:gateway=10.0.0.17
+
−
N1[route]=192.168.11.0/24:gateway=10.0.0.17
+
# 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.13
 +
N1[route]=192.168.12.0/24:gateway=10.0.0.5
 +
N1[route]=192.168.21.0/24:gateway=10.0.0.5
 +
N1[route]=192.168.11.0/24:gateway=10.0.0.9
 +
N1[route]=192.168.22.0/24:gateway=10.0.0.13
 +
 
</syntaxhighlight>
 
</syntaxhighlight>
 
{{collapse bottom}}
 
{{collapse bottom}}
  
−
Para implantar a estrutura DiffServ, deve-se começar com o seguinte:
+
Nessa rede deve-se implantar um serviço do tipo ''Olímpico''. Esse serviço é composto por três classes:
  
−
'''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.
+
*'''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
  
−
'''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.
+
Além disso, clientes podem contratar capacidade da rede para tráfego sensível a atraso (ex: VoIP).
  
−
'''''OBS:''''' os links dentro da rede do provedor estão superdimensionados, portanto não apresentam gargalos.
+
# Implante o serviço Olímpico nessa rede. Ajax contratou um link Ouro, Tabajara contratou Prata, e Lexcorp contratou bronze.
−
<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''.
+
# Modifique a rede para que Ajax e Tabajara contratem Ouro, e Lexcorp contrate Bronze
 +
# Modifique a rede para que Tabajara contrate também capacidade adicional para até 4 chamadas VoIP simultâneas (assuma uso de PCM-u).
 +
# '''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]).
 +
-->
  
−
Tendo a estrutura inicial preparada, resolva os seguintes problemas:
+
* Continuou-se a a atividade proposta na [[RMU-2013-1#Atividade_11|aula de  06/11]].
 +
* Testou-se o software [[VisualTCNG_-_Uma_interface_gr%C3%A1fica_amig%C3%A1vel_para_constru%C3%A7%C3%A3o_de_regras_de_QoS_no_Linux|VisualTC]], desenvolvido no TCC do Luiz Gustavo Ender.
 +
** Deve-se executar o VisualTC na máquina real.
 +
** Deve-se criar a hierarquia de qdisc, e copiar o shell script resultante para dentro do Netkit.
 +
** No Netkit deve-se testar o funcionamento das qdisc geradas.
 +
** Deve-se responder o [https://docs.google.com/spreadsheet/viewform?fromEmail=true&formkey=dEdYeVJzQnA2a2p5Q3FpUkF5SzFGTEE6MA questionário de avaliação do VisualTC].
  
 +
= 13/11: Diffserv (conclusão) =
  
−
'''1)''' O cliente Ajax contratou um link de 1256 kbps, e Tabajara contratou um link de 512 kbps. 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).
+
Foi concluída a atividade proposta na [[RMU-2013-1#Atividade_11|aula de 06/11]].
  
−
'''PARA TESTAR:'''
+
== TAREFA: Pesquisa sobre mecanismos de QoS em roteadores reais ==
−
* Verifique se os pacotes estãop devidamente marcados (isso pode ser feito em N1 usando ''tcpdump'' ou ''wireshark'')
 
−
* Teste se a vazão esperada para dados está sendo obtida. Use o ''netperf'': <syntaxhighlight lang=bash>
 
−
netperf -f k -H IP_do_outro_computador
 
−
</syntaxhighlight>
 
−
* Teste também chamadas VoIP usando o [[RMU-2013-1#Como_testar_chamadas_no_Netkit|siprtp]].
 
  
 +
'''Para próxima 4a feira (20/11):'''
  
−
'''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 PCMU, e que pode haver até 5 streams simultâneas, use a sua estrutura DiffServ para atender essa necessidade.
 
  
−
{{collapse top|Uma possível solução (aproximada) para B1 e B2}}
+
Façam uma pesquisa sobre as disciplinas de fila, mecanismos de condicionamento de tráfego e suporte a Diffserv existentes em roteadores e switches de UM dos seguintes fabricantes:
−
<syntaxhighlight lang=bash>
+
{| border="1"
−
#!/bin/bash
+
!Fabricante
 +
!Aluno
 +
|-
 +
| Cisco || Nicole
 +
|-
 +
| Enterasys|| Maicky
 +
|-
 +
| Alcatel||Francisco
 +
|-
 +
| Juniper||Leandro
 +
|-
 +
| HP/3Com||Liamari
 +
|-
 +
| Huawei||Maycon
 +
|-
 +
| IBM||
 +
|-
 +
|Avaya ||
 +
|-
 +
|D-Link ||Aliny
 +
|}
  
−
IFACE=eth2
+
... e prepare uma curta apresentação mostrando esses mecanismos, o que são capazes de fazer, que parâmetros são tipicamente necessários para usá-los (ex: taxa média, taxa de pico, peso, prioridade, ...), e como são utilizados para implantar Diffserv nesses roteadores.
  
−
tc qdisc del dev $IFACE root
+
OBS: Cada aluno deve escolher um fabricante.
  
−
# adiciona a qdisc raiz na interface eth0
+
= 20/11: IntServ: Serviços Integrados na Internet =
−
tc qdisc add dev $IFACE 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 $IFACE parent 1:0 classid 1:1 htb rate 4000kbit ceil 4000kbit
 
−
 
−
# cria as classes das aplicações
 
−
#AJAX
 
−
tc class add dev $IFACE parent 1:1 classid 1:21 htb prio 2 rate 1256kbit ceil 1256kbit
 
−
# AJAX: EF
 
−
tc class add dev $IFACE parent 1:21 classid 1:31 htb prio 1 rate 450kbit ceil 1256kbit
 
−
# AJAX: AF
 
−
tc class add dev $IFACE parent 1:21 classid 1:32 htb prio 2 rate 806kbit ceil 1256kbit
 
−
# TABAJARA
 
−
tc class add dev $IFACE parent 1:1 classid 1:22 htb prio 2 rate 512kbit ceil 512kbit
 
−
# Outras (melhor esforço) ???
 
−
tc class add dev $IFACE parent 1:1 classid 1:23 htb prio 3 rate 1bps ceil 512kbit
 
−
 
−
# marca os datagramas vindos de Ajax classes AF41 e EF
 
−
# UDP (VoIP) são EF
 
−
iptables -t mangle -A PREROUTING -i eth0 -p udp -j DSCP --set-dscp-class ef
 
−
# Ajax: dados em geral são AF41
 
−
iptables -t mangle -A PREROUTING -i eth0 -j DSCP --set-dscp-class af41
 
  
−
# Tabajara: no momento somente AF31
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-06.pdf Transparências]
−
iptables -t mangle -A PREROUTING -i eth1 -j DSCP --set-dscp-class af31
+
* [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]
 +
* [http://www.cisco.com/en/US/prod/collateral/routers/ps380/prod_case_study0900aecd80345cb3_ps368_Products_Case_Study.html Estudo de caso: Telecom Italia e Cisco]
 +
* [http://www.cisco.com/en/US/prod/collateral/routers/ps5854/prod_case_study0900aecd8039fc1b_ps6557_Products_Case_Study.html Estudo de caso: BAT Italia e Cisco]
  
−
# datagramas da classe DSCP AF41 vão para a fila 1:21
+
'''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.
−
iptables -t mangle -A FORWARD -m dscp --dscp-class af41 -j CLASSIFY --set-class 1:32
 
−
# ... e da classe EF vão para 1:41
 
−
iptables -t mangle -A FORWARD -i eth0 -m dscp --dscp-class ef -j CLASSIFY --set-class 1:31
 
  
−
# datagramas da classe DSCP AF41 vão para a fila 1:22
 
−
iptables -t mangle -A FORWARD -m dscp --dscp-class af31 -j CLASSIFY --set-class 1:22
 
−
</syntaxhighlight>
 
−
{{collapse bottom}}
 
−
{{collapse top|Uma possível solução (aproximada) para N1}}
 
−
<syntaxhighlight lang=bash>
 
−
#!/bin/bash
 
  
−
for IFACE in eth0 eth1; do
+
IntServ é introduzido pela [http://tools.ietf.org/html/rfc1633 RFC 1633].
  
−
  tc qdisc del dev $IFACE root
 
  
−
  # adiciona a qdisc raiz na interface eth0
+
[[imagem:Intserv1.jpeg]]
−
  tc qdisc add dev $IFACE root handle 1:0 htb default 1
 
−
 
−
  # 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 4000kbit ceil 4000kbit
 
−
 
−
  # cria as classes das aplicações
 
−
  tc qdisc add dev $IFACE parent 1:1 handle 2:0 prio
 
−
 
−
  # datagramas da classe DSCP EF vão para a fila 2:1
 
−
  iptables -t mangle -A FORWARD -m dscp --dscp-class ef -j CLASSIFY --set-class 2:1
 
  
−
  # datagramas das classe DSCP AFXX vão para a fila 2:2
 
−
  iptables -t mangle -A FORWARD -m dscp --dscp-class af41 -j CLASSIFY --set-class 2:2
 
−
  iptables -t mangle -A FORWARD -m dscp --dscp-class af31 -j CLASSIFY --set-class 2:2
 
  
−
  # demais datagramas (DSCP BE) vão para a fila 2:3
+
Elementos da arquitetura IntServ:
−
  iptables -t mangle -A FORWARD -j CLASSIFY --set-class 2:3
+
* '''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.
  
−
done
 
−
</syntaxhighlight>
 
−
{{collapse bottom}}
 
  
−
'''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 GSM, e a stream de video use 256 kbps, use a estrutura DiffServ para atender essa demanda.
+
[[imagem:Intserv-model.jpg]]
 +
 
 +
 
 +
A sinalização RSVP ocorre em duas etapas:
 +
# 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.
  
 +
[[imagem:Rsvp-signaling.jpg]]
  
−
'''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 [http://www.opalsoft.net/qos/DS-27.htm GRED]).
 
  
−
= 26/06: DiffServ em roteador Linux (continuação) =
+
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''':
 +
* 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.
  
  
−
<!-- Para concluir o estudo sobre Diffserv, será feito um projeto com esta outra rede:
+
... 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.
  
−
[[imagem:Diffserv-rede2.png]]
+
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:
  
  
−
{{collapse top|Configuração para o Netkit}}
 
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
−
B1[type]=gateway
+
Although IntServ is a straightforward QoS model, end-to-end service guarantees cannot be supported unless all
−
B2[type]=gateway
+
nodes along the route support IntServ. This is obviously so because any best-effort node along any route can
−
B3[type]=gateway
+
treat packets in such a way that the end-to-end service agreements are violated. In the case of end-end
−
B4[type]=gateway
+
implementation of IntServ QoS model, it is recognized by the industry that the support of per-flow guarantees
−
N1[type]=gateway
+
in the core of the Internet will pose severe scalability problems. Therefore, scalability is a key
−
Ajax1[type]=generic
+
architectural concern for IntServ, since it requires end-to-end signaling and must maintain a per-flow
−
Ajax2[type]=generic
+
soft state at every router along the path. Other concerns are, how to authorize and prioritize
−
Tabajara1[type]=generic
+
reservation requests, and what happens when signaling is not deployed end-to-end. Because of
−
Tabajara2[type]=generic
+
these issues, it is generally accepted that IntServ is a better candidate for enterprise
−
Lexcorp1[type]=generic
+
networks (i.e., for access networks), where user flows can be managed at the desktop user level,
−
Lexcorp2[type]=generic
+
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
−
# Preservando o script que cria as regras de QoS nos roteadores.
+
service architecture concept.
−
# OBS: não esqueça de exportar o projeto do Netkit após terminar a execução da rede ! Ver menu File->Export ...
+
</syntaxhighlight>
−
B1[preserve]=/root/firewall.sh
+
 
−
B2[preserve]=/root/firewall.sh
+
== Atividade ==
−
B3[preserve]=/root/firewall.sh
+
 
−
B4[preserve]=/root/firewall.sh
+
* [[RMU-2012-2#06.2F12:_Simula.C3.A7.C3.A3o_com_Opnet|Instalação do Opnet]]
−
N1[preserve]=/root/firewall.sh
+
** [http://tele.sj.ifsc.edu.br/~msobral/rmu/op-licenca.tgz Arquivo de licenca (descompacte em /home/aluno)]
−
+
 
−
# Links ...
+
Para visualizar o efeito de usar IntServ, iremos utilizar o simulador Opnet.
−
B1[eth0]=link-ajax1:ip=192.168.1.254/24
+
# Execute o simulador e abra o modelo ''RSVP''.
−
B1[eth1]=link-n1-b1:ip=10.0.0.1/30
+
## Leia a descrição do modelo, que explica o que ele pretende mostrar.
−
B2[eth0]=link-tab2:ip=192.168.12.254/24
+
## No menu ''Scenarios->Switch scenario'' selecione ''configuration''. Em  seguida, execute o modelo.
−
B2[eth1]=link-lex1:ip=192.168.21.254/24
+
## Selecione o menu ''Results-Compare results'' para visualizar os resultados, observando os atrasos fim-a-fim nos sistemas finais e nos roteadores.
−
B2[eth2]=link-n1-b2:ip=10.0.0.5/30
+
## 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''.
−
B3[eth0]=link-tab1:ip=192.168.11.254/24
+
# 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''.
−
B3[eth1]=link-n1-b3:ip=10.0.0.9/30
+
## Execute o modelo com a nova especificação de fluxo.
−
B4[eth0]=link-ajax2:ip=192.168.2.254/24
+
## Visualize os resultados. O que mudou em relação à primeira execução ?
−
B4[eth1]=link-lex2:ip=192.168.22.254/24
+
# Qual o efeito de haver um roteador sem suporte a RSVP no meio do caminho ?
−
B4[eth2]=link-n1-b4:ip=10.0.0.13/30
+
## 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''.
−
N1[eth0]=link-n1-b1:ip=10.0.0.2/30
+
## Refaça a simulação, e observe os resultados. O que mudou em relação ao atraso fim-a-fim ?
−
N1[eth1]=link-n1-b2:ip=10.0.0.6/30
+
# Ainda sobre o roteador sem RSVP que foi adicionado, faça a seguinte modificação:
−
N1[eth2]=link-n1-b3:ip=10.0.0.10/30
+
## Conecte o computador ''client_no_RSVP'' ao novo roteador (e desconecte-o de ''Router 1''). Use um link ''PP DS0'.
−
N1[eth3]=link-n1-b4:ip=10.0.0.14/30
+
## 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.
−
Ajax1[eth0]=link-ajax1:ip=192.168.1.1/24
+
 
−
Ajax2[eth0]=link-ajax2:ip=192.168.2.1/24
+
 
−
+
[[imagem:Rsvp-model-2.png|600px]]
−
Tabajara1[eth0]=link-tab1:ip=192.168.11.1/24
+
<br>''O modelo RSVP com mais um roteador.''
−
Tabajara2[eth0]=link-tab2:ip=192.168.12.1/24
+
 
−
+
<!-- === Sobre o bug no Opnet ===
−
Lexcorp1[eth0]=link-lex1:ip=192.168.21.1/24
+
 
−
Lexcorp2[eth0]=link-lex2:ip=192.168.22.1/24
+
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 ?).
−
+
 
−
# Rotas ...
+
'''Solução:'''
−
Ajax1[default_gateway]=192.168.1.254
+
# Remova todo o subdiretório ''.cxoffice'':<syntaxhighlight lang=bash>rm -rf /home/aluno/.cxoffice</syntaxhighlight>
−
Ajax2[default_gateway]=192.168.2.254
+
# Reinstale o simulador: <syntaxhighlight lang=bash>cd /home/aluno
−
Tabajara1[default_gateway]=192.168.11.254
+
wget http://172.18.200.251/~msobral/opnet.tgz
−
Tabajara2[default_gateway]=192.168.12.254
+
tar xzf opnet.tgz</syntaxhighlight>
−
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.13
 
−
N1[route]=192.168.12.0/24:gateway=10.0.0.5
 
−
N1[route]=192.168.21.0/24:gateway=10.0.0.5
 
−
N1[route]=192.168.11.0/24:gateway=10.0.0.9
 
−
N1[route]=192.168.22.0/24:gateway=10.0.0.13
 
−
 
−
</syntaxhighlight>
 
−
{{collapse bottom}}
 
  
−
Nessa rede deve-se implantar um serviço do tipo ''Olímpico''. Esse serviço é composto por três classes:
+
== TAREFA: Leitura da semana ==
  
−
*'''Ouro:''' provê links de 2 Mbps com tolerância a rajadas de até 512 kB
+
Leia os dois textos abaixo, e preparem uma breve apresentação para '''dia 27/11''' que explique os conceitos básicos de MPLS-Diffserv e MPLS-TE, e compare-os evidenciando suas características e diferenças.
−
*'''Prata:''' provê links de 1 Mbps com tolerância a rajadas de até 256 kB
+
* Leiam até a seção 3.2 (inclusive) [http://tele.sj.ifsc.edu.br/~msobral/rmu/MPLS%20DiffServ-aware%20Traffic%20Engineering.pdf deste texto sobre MPLS e Diffserv]
−
*'''Bronze:''' provê links que aproveitam a capacidade ociosa da rede, porém limitados a 2 Mbps
+
* Leiam [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.
  
−
Além disso, clientes podem contratar capacidade da rede para tráfego sensível a atraso (ex: VoIP).
+
= 22/11: Firewall =
  
−
# Implante o serviço Olímpico nessa rede. Ajax contratou um link Ouro, Tabajara contratou Prata, e Lexcorp contratou bronze.
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-08.pdf Transparências]
−
# Modifique a rede para que Ajax e Tabajara contratem Ouro, e Lexcorp contrate Bronze
+
* [http://www.sans.org/reading_room/whitepapers/firewalls/ Uma coleção de textos técnicos sobre firewalls e suas aplicações]
−
# Modifique a rede para que Tabajara contrate também capacidade adicional para até 4 chamadas VoIP simultâneas (assuma uso de PCM-u).
 
−
# '''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]).
 
−
-->
 
  
−
Continuou-se a a atividade proposta na [[RMU-2013-1#Atividade_11|aula de  20/06]].
+
== Uma introdução ao iptables ==
  
−
= 27/06: Diffserv (conclusão) =
+
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).
  
−
Foi concluída a atividade proposta na [[RMU-2013-1#Atividade_11|aula de  20/06]].
+
[[imagem:Iptables-fluxo-filter.png]]
  
−
== TAREFA: Leitura da semana ==
 
  
−
'''Para próxima 4a feira (03/07):'''
+
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.
  
  
−
Façam uma pesquisa sobre as disciplinas de fila, mecanismos de condicionamento de tráfego e suporte a Diffserv existentes em roteadores e switches de UM dos seguintes fabricantes:
+
[[imagem:Iptables-chains.png|400px]]
−
* Cisco
 
−
* Enterasys
 
−
* Alcatel
 
−
* Juniper
 
−
* 3Com
 
−
... e prepare uma curta apresentação mostrando esses mecanismos, o que são capazes de fazer, que parâmetros são tipicamente necessários para usá-los (ex: taxa média, taxa de pico, peso, prioridade, ...), e como são utilizados para implantar Diffserv nesses roteadores.
 
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/filas.pdf Contribuição da Patrícia]
 
  
−
= 03/07: IntServ: Serviços Integrados na Internet =
+
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.
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-06.pdf Transparências]
+
Por exemplo, a regra abaixo permite o encaminhamento de todos os segmentos TCP destinados a porta 80:
−
* [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]
 
  
−
'''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.
 
  
 +
[[imagem:Iptables-intro.png]]
  
−
IntServ é introduzido pela [http://tools.ietf.org/html/rfc1633 RFC 1633].
 
  
 +
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].
  
−
[[imagem:Intserv1.jpeg]]
+
{| border="1" cellpadding="2"
−
 
+
!Opção
−
 
+
!Descrição
−
Elementos da arquitetura IntServ:
+
!Exemplo
−
* '''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''
+
| -s IP[/Mascara] || endereço IP de origem|| -s 200.135.37.64/26
−
** '''''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.
+
| -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:<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
 +
|}
  
  
−
[[imagem:Intserv-model.jpg]]
+
Os alvos definem o que fazer com um pacote selecionado por uma regra. As ações possíveis estão listadas abaixo:
  
  
−
A sinalização RSVP ocorre em duas etapas:
+
{| border="1" cellpadding="2"
−
# O transmissor do fluxo envia mensagens PATH para o receptor. Essas mensagens contém a descrição do fluxo (''TSpec'').
+
!Alvo
−
# 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.
+
!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
 +
|}
  
−
'''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]]
+
=== 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: <syntaxhighlight lang=bash>
 +
iptables-save > minhas_regras
 +
</syntaxhighlight>
 +
* '''iptables-restore''': instala as regras lidas da entrada padrão, normalmente redirecionada de um arquivo: <syntaxhighlight lang=bash>
 +
iptables-restore < minhas_regras
 +
</syntaxhighlight>
  
−
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.
 
  
 +
Cada aluno deve implantar a seguinte rede virtual em seu computador:
  
−
... 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 [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:
+
[[imagem: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''):
  
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
−
Although IntServ is a straightforward QoS model, end-to-end service guarantees cannot be supported unless all
+
# Obs: substitua X pelo número do seu computador
−
nodes along the route support IntServ. This is obviously so because any best-effort node along any route can
+
pc[type]=generic
−
treat packets in such a way that the end-to-end service agreements are violated. In the case of end-end
+
firewall[type]=gateway
−
implementation of IntServ QoS model, it is recognized by the industry that the support of per-flow guarantees
+
#internet[type]=generic
−
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>
 
  
−
== Atividade ==
+
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
  
−
* [[RMU-2012-2#06.2F12:_Simula.C3.A7.C3.A3o_com_Opnet|Instalação do Opnet]]
+
pc[default_gateway]=10.1.X.254
−
** [http://tele.sj.ifsc.edu.br/~msobral/rmu/op-licenca.tgz Arquivo de licenca (descompacte em /home/aluno)]
+
firewall[default_gateway]=192.168.2.1
 +
#internet[default_gateway]=192.168.2.100+x/24
 +
</syntaxhighlight>
  
−
Para visualizar o efeito de usar IntServ, iremos utilizar o simulador Opnet.
+
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''.
−
# 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.
 
  
 +
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.
  
−
[[imagem:Rsvp-model-2.png|600px]]
+
=== DICA ===
−
<br>''O modelo RSVP com mais um roteador.''
 
  
−
<!-- === Sobre o bug no Opnet ===
+
É útil ativar o NAT na interface externa do firewall (eth0 na nossa rede de teste):
  
−
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 ?).
+
<syntaxhighlight lang=bash>
 +
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
 +
</syntaxhighlight>
  
−
'''Solução:'''
+
=== Cenário 1: Uma rede pequena sem servidores ===
−
# 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>
 
−
-->
 
  
−
== TAREFA: Leitura da semana ==
+
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>
 +
#!/bin/bash
  
−
Leia os dois textos abaixo, e preparem uma breve apresentação para '''dia 10/07''' que explique os conceitos básicos de MPLS-Diffserv e MPLS-TE, e compare-os evidenciando suas características e diferenças.
+
# Limpa as regras existentes
−
* Leiam até a seção 3.2 (inclusive) [http://tele.sj.ifsc.edu.br/~msobral/rmu/MPLS%20DiffServ-aware%20Traffic%20Engineering.pdf deste texto sobre MPLS e Diffserv]
+
iptables -F
−
* Leiam [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.
 
  
−
= 04/07: Firewall =
+
# As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-08.pdf Transparências]
+
# Por default, bloqueia tudo
−
* [http://www.sans.org/reading_room/whitepapers/firewalls/ Uma coleção de textos técnicos sobre firewalls e suas aplicações]
+
iptables -P FORWARD DROP
  
−
== Uma introdução ao iptables ==
+
# Libera todos pacotes TCP que entrarem pela interface eth1
 +
iptables -A FORWARD -i eth1 -p tcp -j ACCEPT
  
−
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:
+
# Libera pacotes UDP destinados a porta 53 (DNS), contanto que tenham entrado pela interface eth1
−
* '''INPUT:''' contém as regras a serem aplicadas aos pacotes destinados ao próprio firewall.
+
iptables -A FORWARD -i eth1 -p udp --dport 53 -j ACCEPT
−
* '''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.
 
  
 +
# 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
  
−
[[imagem:Iptables-chains.png|400px]]
+
# 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
  
  
−
Uma regra deve especificar basicamente três coisas:
+
# Libera segmentos TCP vindos pela interface eth0 e que não tenham a flags SYN acesa (pertencem a conexões estabelecidas)
−
* '''Chain''': em que ''chain'' deve ser adicionada.
+
iptables -A FORWARD -i eth0 -p tcp ! --syn -j ACCEPT
−
* '''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:
+
</syntaxhighlight>
 +
#* Com filtro ''stateful'': <syntaxhighlight lang=bash>
 +
#!/bin/bash
  
 +
# Limpa as regras existentes
 +
iptables -F
  
−
[[imagem:Iptables-intro.png]]
+
# 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
  
−
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].
+
# Libera pacotes que iniciem novos fluxos, originados na rede interna (interface eth1)
 +
iptables -A FORWARD -i eth1 -m state --state NEW -j ACCEPT
  
−
{| border="1" cellpadding="2"
+
# Regra default eh descartar
−
!Opção
+
iptables -P FORWARD DROP
−
!Descrição
+
</syntaxhighlight>
−
!Exemplo
+
# ''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
−
| -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:<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
 
−
|}
 
  
 +
# Libera todos pacotes de fluxos estabelecidos
 +
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
  
−
Os alvos definem o que fazer com um pacote selecionado por uma regra. As ações possíveis estão listadas abaixo:
+
# 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
  
−
{| border="1" cellpadding="2"
+
# Descarta demais pacotes
−
!Alvo
+
iptables -A FORWARD -j DROP</syntaxhighlight>
−
!Descrição
+
#* Versão alternativa, usando o módulo ''multiport'': <syntaxhighlight lang=bash>
−
!Exemplo
+
# As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall
−
|-
 
−
| 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
 
−
|}
 
  
 +
# Libera todos pacotes de fluxos estabelecidos
 +
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
  
−
=== Salvando e restaurando regras do iptables ===
+
# 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
  
−
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:
+
# Libera segmentos TCP destinados as portas 80 (HTTP) e 443 (HTTPS), contanto que tenham se originado na rede interna
−
* '''iptables-save''': escreve as regras atuais na saída padrão, que normalmente é redirecionada para um arquivo: <syntaxhighlight lang=bash>
+
iptables -A FORWARD -i eth1 -p tcp -m multiport  --dports 80,443 -m state --state NEW -j ACCEPT
−
iptables-save > minhas_regras
 
−
</syntaxhighlight>
 
−
* '''iptables-restore''': instala as regras lidas da entrada padrão, normalmente redirecionada de um arquivo: <syntaxhighlight lang=bash>
 
−
iptables-restore < minhas_regras
 
−
</syntaxhighlight>
 
  
−
== Atividade ==
+
# 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.
 +
#* ''Dica:'' dêem uma olhada no módulo [http://l7-filter.sourceforge.net/ l7], criado para estender o Netfilter.
 +
#* [http://security.stackexchange.com/questions/33983/what-are-the-tcp-udp-ports-used-by-torrent-applications Uma boa explicação encontrada na rede ...]
  
−
Cada aluno deve implantar a seguinte rede virtual em seu computador:
+
= 23/11: Firewall =
  
 +
Realização dos exercícios da aula de [[RMU-2013-2#22.2F11:_Firewall|22/11]], mais este aqui:
  
−
[[imagem:Lab-firewall-intro.png]]
+
== Atividade ==
  
 +
Na rede dos exercícios, inicie uma chamada VoIP entre o PC e o computador do professor (192.168.2.1). Para quem usou o [[Netkit]], a chamada deve ser simulada com o ''siprtp'':
  
−
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=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.
  
 +
* Regras específicas para as chamadas VoIP (Obs: PBX=192.168.2.101, e ports RTP configuradas no Asterisk vão de 36540 a 36999):
 
<syntaxhighlight lang=text>
 
<syntaxhighlight lang=text>
−
# Obs: substitua X pelo número do seu computador
+
iptables -A FORWARD -i $WAN -s 192.168.2.101 --sport 36540:36999 -d 10.1.X.0/24 -j ACCEPT
−
pc[type]=generic
+
iptables -A FORWARD -i $LAN -d 192.168.2.101 --dport 36540:36999 -s 10.1.X.0/24 -j ACCEPT
−
firewall[type]=gateway
+
iptables -A FORWARD -i $LAN -d 192.168.2.101 --dport 5060 -s 10.1.X.0/24 -m state --state NEW -j ACCEPT
−
#internet[type]=generic
+
</syntaxhighlight>
  
−
pc[eth0]=link:ip=10.1.X.1/24
+
== TAREFA: Leitura da semana ==
−
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
+
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 discuti-lo com o professor na aula de 04/12. Leiam as seções "Introduction" e "Firewall Limitations" (o restante é propagando de um produto).
−
firewall[default_gateway]=192.168.2.1
 
−
#internet[default_gateway]=192.168.2.100+x/24
 
−
</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''.
+
= 27/11: Firewall =
  
−
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.
+
... continuação dos exercícios da aula anterior.
  
−
=== DICA ===
+
= 29/11: Firewall =
  
−
É útil ativar o NAT na interface externa do firewall (eth0 na nossa rede de teste):
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-08.pdf Transparências]
  
−
<syntaxhighlight lang=bash>
+
* Projetos de firewalls (ver transparências)
−
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
+
** Estratégias de implantação de firewalls
−
</syntaxhighlight>
+
** 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]
  
−
=== 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:
+
'''Fluxo de processamento do Netfilter:'''
−
# ''Caso 1:'' os computadores internos podem acessar qualquer serviço externo.
 
−
#* Com filtro ''stateless'': <syntaxhighlight lang=bash>
 
−
#!/bin/bash
 
  
−
# Limpa as regras existentes
+
[[imagem:Iptables-fluxograma.png|800px]]
−
iptables -F
 
  
−
# As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall
 
  
−
# Por default, bloqueia tudo
+
== Dicas para NAT ==
−
iptables -P FORWARD DROP
 
  
−
# Libera todos pacotes TCP que entrarem pela interface eth1
+
* Fazendo NAT de todo o tráfego que sai pela interface eth0: <syntaxhighlight lang=bash>
−
iptables -A FORWARD -i eth1 -p tcp -j ACCEPT
+
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>
  
−
# Libera pacotes UDP destinados a porta 53 (DNS), contanto que tenham entrado pela interface eth1
+
== Ativando e desativando as regras do filtro IP (iptables) ==
−
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
+
O seguinte script, que deve ser salvo com o nome ''firewall.sh'', pode ser usado para ativar e desativar as regras do filtro IP:
−
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)
+
<syntaxhighlight lang=bash>
−
iptables -A FORWARD -i eth0 -p tcp --tcp-flags SYN,ACK SYN,ACK -j ACCEPT
+
#!/bin/bash
 +
# Variaveis
 +
DEV_LAN=eth0
 +
DEV_WAN=eth1
  
 +
fw_start(){
 +
  # Adicionando regras
 +
  iptables -A INPUT -i $DEV_LAN -j ACCEPT
 +
}
  
−
# Libera segmentos TCP vindos pela interface eth0 e que não tenham a flags SYN acesa (pertencem a conexões estabelecidas)
+
fw_stop(){
−
iptables -A FORWARD -i eth0 -p tcp ! --syn -j ACCEPT
+
  # 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>
 
</syntaxhighlight>
−
#* Com filtro ''stateful'': <syntaxhighlight lang=bash>
 
−
#!/bin/bash
 
  
−
# Limpa as regras existentes
+
* Iniciando o firewall: <syntaxhighlight lang=bash>
−
iptables -F
+
./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>
  
−
# As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall
+
== Atividade 1: firewall/roteador para rede doméstica ==
  
−
# Libera todos pacotes de fluxos estabelecidos
+
Uma pequena rede possui um firewall com algumas regras básicas para protegê-la do mundo externo:
−
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
+
* 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
  
−
# Libera pacotes que iniciem novos fluxos, originados na rede interna (interface eth1)
+
== Atividade 2: serviço SMTP rodando em rede com NAT ==
−
iptables -A FORWARD -i eth1 -m state --state NEW -j ACCEPT
 
  
−
# Regra default eh descartar
+
[[imagem:Fw-lab3.png]]
−
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
+
* Política padrão: '''negar tudo''' (entrada e roteamento)
−
iptables -A FORWARD -i eth1 -p udp --dport 53 -m state --state NEW -j ACCEPT
+
* 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.
  
−
# Libera segmentos TCP destinados as portas 80 (HTTP) e 443 (HTTPS), contanto que tenham se originado na rede interna
+
Obs: para monitorar quantos pacotes estão casando com as regras:
−
iptables -A FORWARD -i eth1 -p tcp --dport 80 -m state --state NEW -j ACCEPT
+
<syntaxhighlight lang=bash>
−
iptables -A FORWARD -i eth1 -p tcp --dport 443 -m state --state NEW -j ACCEPT
+
watch iptables -t filter -L -v
 +
</syntaxhighlight>
  
−
# Descarta demais pacotes
+
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:
−
iptables -A FORWARD -j DROP</syntaxhighlight> -->
+
<syntaxhighlight lang=bash>
−
#* Versão alternativa, usando o módulo ''multiport'': <!-- <syntaxhighlight lang=bash>
+
# limita as cconexões ao servidor web: no máximo 2 por segundo
−
# As regras são inseridas na chain FORWARD, pois tratam de pacotes em trânsito pelo firewall
+
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>
  
−
# Libera todos pacotes de fluxos estabelecidos
+
{{collapse top | Configuração para Netkit}}
−
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
+
<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}}
  
−
# Libera datagramas UDP destinados a porta 53 (DNS), contanto que tenham se originado na rede interna
+
{{collapse top | Exemplo de regras}}
−
iptables -A FORWARD -i eth1 -p udp --dport 53 -m state --state NEW -j ACCEPT
+
<syntaxhighlight lang=bash>
 +
#!/bin/bash
  
−
# Libera segmentos TCP destinados as portas 80 (HTTP) e 443 (HTTPS), contanto que tenham se originado na rede interna
+
# Variaveis
−
iptables -A FORWARD -i eth1 -p tcp -m multiport  --dports 80,443 -m state --state NEW -j ACCEPT
+
DEV_LAN=eth1
 +
DEV_WAN=eth0
 +
 +
fw_start(){
 +
  # Adicionando regras
 +
  iptables -P FORWARD DROP
  
−
# Descarta demais pacotes
+
  iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
−
iptables -A FORWARD -j DROP</syntaxhighlight> -->
+
  iptables -A FORWARD -i $DEV_LAN -p tcp --dport 25 -m state --state NEW -j ACCEPT
−
# ''Caso 3:'' os computadores internos podem acessar qualquer serviço, com exceção de redes eDonkey (ex: emule) e torrent.
+
  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
  
−
= 10/07: Firewall =
+
  # NAT
 +
  iptables -t nat -A POSTROUTING -o $DEV_WAN -j MASQUERADE
  
−
Realização dos exercícios da aula de [[RMU-2012-2#21.2F02:_Firewall|04/07]], mais este aqui:
+
  # 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
  
−
== 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'':
+
fw_stop(){
−
 
+
  # Limpando as regras
−
<syntaxhighlight lang=bash>
+
  iptables -P INPUT ACCEPT
−
siprtp --ip-addr=10.1.X.1 sip:0@192.168.2.1
+
  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>
 
</syntaxhighlight>
−
 
+
{{collapse bottom}}
−
Configure seu filtro de pacotes para que essa chamada possa ser realizada a contento.
 
  
 
== TAREFA: Leitura da semana ==
 
== 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 16/07. Leiam as seções "Introduction" e "Firewall Limitations" (o restante é propagando de um produto).
+
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 discuti-lo na aula de 06/12. Leiam as seções 1 a 4 (se quiserem ler todo o resto, fiquem à vontade ;-).
  
−
= 11/07: Firewall =
+
= 04/12: Lista de exercícios: Firewall =
  
−
... continuação dos exercícios da aula anterior.
+
Nesta aula a turma se organizará em grupos, que devem resolver o seguinte problema:
  
−
= 17/07: Firewall =
+
[[imagem:Fw-lista1.png]]
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-08.pdf Transparências]
 
  
−
* Projetos de firewalls (ver transparências)
+
A rede acima é composta de dois segmentos, ambos implantados com subredes IP com endereços não roteáveis:
−
** Estratégias de implantação de firewalls
+
* '''DMZ:''' contém servidores que podem sere acessados a partir da rede externa.
−
** Perímetro de segurança
+
* '''Rede interna:''' contém computadores que não podem ser acessados de fora.
−
** 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]
 
  
 +
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.
  
−
'''Fluxo de processamento do Netfilter:'''
+
Obs: quem quiser fazer o exercício com o [[Netkit]] pode usar o seguinte modelo para a rede:
  
−
[[imagem:Iptables-fluxograma.png|800px]]
+
<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>
  
−
== Dicas para NAT ==
+
{{collapse top|Uma possível solução}}
−
 
+
<syntaxhighlight lang=bash>
−
* Fazendo NAT de todo o tráfego que sai pela interface eth0: <syntaxhighlight lang=bash>
+
# bloqueia tudo por default
−
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
+
iptables -P INPUT DROP
−
</syntaxhighlight>
+
iptables -P FORWARD DROP
−
* 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) ==
+
# redireciona os ports smtp, dns, ssh, http e https para os servidores
 +
# da DMZ
 +
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2
 +
iptables -t nat -A PREROUTING -i eth0 -p udp -m udp --dport 53 -j DNAT --to-destination 10.0.0.2
 +
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 10.0.0.2:22
 +
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 2200 -j DNAT --to-destination 10.0.0.1:22
 +
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80
 +
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.1
  
−
O seguinte script, que deve ser salvo com o nome ''firewall.sh'', pode ser usado para ativar e desativar as regras do filtro IP:
+
# Faz NAT de tudo que sai em direcao a Internet
 +
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  
−
<syntaxhighlight lang=bash>
+
# Libera pacotes de fluxos estabelecidos
−
#!/bin/bash
+
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
−
# Variaveis
 
−
DEV_LAN=eth0
 
−
DEV_WAN=eth1
 
  
−
fw_start(){
+
# Libera novos fluxos vindos da rede interna em direcao a Internet
−
  # Adicionando regras
+
iptables -A FORWARD -i eth2 -o eth0 -m state --state NEW -j ACCEPT
−
  iptables -A INPUT -i $DEV_LAN -j ACCEPT
 
−
}
 
  
−
fw_stop(){
+
# Libera ports smtp,ssh,dns,http e https para os servidores da DMZ
−
  # Limpando as regras
+
iptables -A FORWARD -p tcp --dport 25 -d 10.0.0.2 -m state --state NEW -j ACCEPT
−
  iptables -P INPUT ACCEPT
+
iptables -A FORWARD -p tcp --dport 22 -d 10.0.0.2 -m state --state NEW -j ACCEPT
−
  iptables -t filter -F
+
iptables -A FORWARD -p udp --dport 53 -d 10.0.0.2 -m state --state NEW -j ACCEPT  
−
  iptables -t nat -F
+
iptables -A FORWARD -p tcp --dport 22 -d 10.0.0.1 -m state --state NEW -j ACCEPT
−
}
+
iptables -A FORWARD -p tcp --dport 80 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 +
iptables -A FORWARD -p tcp --dport 443 -d 10.0.0.1 -m state --state NEW -j ACCEPT
  
−
fw_uso(){
+
# registra todos os pacotes bloqueados
−
  # Mensagem de ajuda
+
iptables -A FORWARD -j LOG
−
  echo "Sintaxe errada..."
+
iptables -A INPUT -j LOG
−
  echo "./$0 (start|stop)"
 
−
}
 
−
 
 
−
case $1 in
 
−
  start)
 
−
    fw_start
 
−
    ;;
 
−
  stop)
 
−
    fw_stop
 
−
    ;;
 
−
  *)
 
−
    fw_uso
 
−
    ;;
 
−
esac
 
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
{{collapse bottom}}
  
−
* Iniciando o firewall: <syntaxhighlight lang=bash>
+
== Estendendo as regras do firewall ==
−
./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 ==
+
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.
 +
* '''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).
  
−
Uma pequena rede possui um firewall com algumas regras básicas para protegê-la do mundo externo:
+
{{collapse top|Uma possível solução}}
−
* Política padrão: '''negar tudo''' (entrada e roteamento)
+
<syntaxhighlight lang=bash>
−
* Usuários da rede local só podem navegar na web, acessar email (POP3, IMAP, SMTP)
+
# bloqueia tudo por default
−
* Firewall pode ser administrado remotamente via SSH, não importando a origem da conexão.
+
iptables -P INPUT DROP
−
** Para dificultar ataques por varredura de portas, o servidor SSH deve atender conexões em uma porta diferente da 22.
+
iptables -P FORWARD DROP
−
* Registrar todas conexões oriundas da rede externa
 
  
−
== Atividade 2: serviço SMTP rodando em rede com NAT ==
+
# redireciona os ports smtp, dns, ssh, http e https para os servidores
 +
# da DMZ
 +
iptables -t nat -A PREROUTING -i eth2 -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2  
 +
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2
 +
iptables -t nat -A PREROUTING -i eth0 -p udp -m udp --dport 53 -j DNAT --to-destination 10.0.0.2
 +
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 10.0.0.2:22
 +
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 2200 -j DNAT --to-destination 10.0.0.1:22
 +
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80
 +
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.1
  
−
[[imagem:Fw-lab3.png]]
+
# Faz NAT de tudo que sai em direcao a Internet
 +
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  
 +
# libera fluxos já estabelecidos para o firewall
 +
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
  
−
* Política padrão: '''negar tudo''' (entrada e roteamento)
+
# libera acesso vindo da rede interna ao proxy http no firewall.
−
* Permitir pings a uma taxa máxima de 10 pacotes por minuto
+
iptables -A INPUT -i eth2 -p tcp --dport 3128 -m state --state NEW -j ACCEPT
−
* 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:
+
# libera acesso vindo de qualquer lugar a ssh no firewall.
−
<syntaxhighlight lang=bash>
+
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
−
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:
+
# libera novos fluxos e fluxos já estabelecidos vindos do firewall
−
<syntaxhighlight lang=bash>
+
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
−
# limita as cconexões ao servidor web: no máximo 2 por segundo
+
iptables -A OUTPUT -m state --state NEW -j ACCEPT  
−
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}}
+
# Libera pacotes de fluxos estabelecidos
−
<syntaxhighlight lang=text>
+
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
−
# 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}}
+
# Bloqueia conexoes para web e smtp na Internet vindos da rede interna
−
<syntaxhighlight lang=bash>
+
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 80 -j DROP
−
#!/bin/bash
+
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 8080 -j DROP
 +
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 443 -j DROP
 +
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 3128 -j DROP
 +
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 25 -j DROP
  
−
# Variaveis
+
# Libera novos fluxos vindos da rede interna em direcao a Internet
−
DEV_LAN=eth1
+
iptables -A FORWARD -i eth2 -o eth0 -m state --state NEW -j ACCEPT
−
DEV_WAN=eth0
 
−
 
−
fw_start(){
 
−
  # Adicionando regras
 
−
  iptables -P FORWARD DROP
 
  
−
  iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
+
# Libera conexoes smtp e consultas DNS vindas da DMZ
−
  iptables -A FORWARD -i $DEV_LAN -p tcp --dport 25 -m state --state NEW -j ACCEPT
+
iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 25 -s 10.0.0.2 -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 eth1 -o eth0 -p udp --dport 53 -s 10.0.0.2 -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
+
# Libera ports smtp,ssh,dns,http e https para os servidores da DMZ
−
  iptables -t nat -A POSTROUTING -o $DEV_WAN -j MASQUERADE
+
iptables -A FORWARD -p tcp --dport 25 -d 10.0.0.2 -m state --state NEW -j ACCEPT
 +
iptables -A FORWARD -p tcp --dport 22 -d 10.0.0.2 -m state --state NEW -j ACCEPT
 +
iptables -A FORWARD -p udp --dport 53 -d 10.0.0.2 -m state --state NEW -j ACCEPT
 +
iptables -A FORWARD -p tcp --dport 22 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 +
iptables -A FORWARD -p tcp --dport 80 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 +
iptables -A FORWARD -p tcp --dport 443 -d 10.0.0.1 -m state --state NEW -j ACCEPT
  
−
  # Redirecionamentos ...
+
# registra todos os pacotes bloqueados
−
  iptables -t nat -A PREROUTING -i $DEV_LAN -p tcp --dport 25 -j DNAT --to-destination 192.168.2.1
+
iptables -A FORWARD -j LOG
−
  iptables -t nat -A PREROUTING -i $DEV_WAN -p tcp --dport 2200 -j DNAT --to-destination 10.1.1.1:22
+
iptables -A INPUT -j LOG
 +
</syntaxhighlight>
 +
{{collapse bottom}}
  
−
}
+
{{collapse top|Outra possível solução, e que explora a hierarquização de chains}}
−
+
<syntaxhighlight lang=bash>
−
fw_stop(){
+
# bloqueia tudo por default
−
  # Limpando as regras
+
iptables -P INPUT DROP
−
  iptables -P INPUT ACCEPT
+
iptables -P FORWARD DROP
−
  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 ==
+
# Cria uma nova chain na tabela nat, para conter as regras que
 +
# se aplicam a pacotes vindos da Internet.
 +
iptables -t nat -N vindo_de_fora
  
−
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 24/07. Leiam as seções 1 a 4 (se quiserem ler todo o resto, fiquem à vontade ;-).
+
# redireciona os ports smtp, dns, ssh, http e https para os servidores
 +
# da DMZ
 +
iptables -t nat -A PREROUTING -i eth2 -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2
 +
iptables -t nat -A PREROUTING -i eth0 -j vindo_de_fora
 +
iptables -t nat -A vindo_de_fora -p udp -m udp --dport 53 -j DNAT --to-destination 10.0.0.2
 +
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2
 +
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 2201 -j DNAT --to-destination 10.0.0.2:22
 +
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 2200 -j DNAT --to-destination 10.0.0.1:22
 +
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80
 +
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.1
  
−
= 18/07: Lista de exercícios: Firewall =
+
# Faz NAT de tudo que sai em direcao a Internet
 +
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  
−
Nesta aula a turma se organizará em grupos, que devem resolver o seguinte problema:
+
# libera fluxos já estabelecidos para o firewall
 +
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
  
−
[[imagem:Fw-lista1.png]]
+
# libera acesso vindo da rede interna ao proxy http no firewall.
 +
iptables -A INPUT -i eth2 -p tcp --dport 3128 -m state --state NEW -j ACCEPT
  
 +
# libera acesso vindo de qualquer lugar a ssh no firewall.
 +
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
  
−
A rede acima é composta de dois segmentos, ambos implantados com subredes IP com endereços não roteáveis:
+
# libera novos fluxos e fluxos já estabelecidos vindos do firewall
−
* '''DMZ:''' contém servidores que podem sere acessados a partir da rede externa.
+
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
−
* '''Rede interna:''' contém computadores que não podem ser acessados de fora.
+
iptables -A OUTPUT -m state --state NEW -j ACCEPT
 +
 
 +
iptables -N vindo_da_rede_interna
 +
iptables -N vindo_da_dmz
 +
iptables -N indo_para_dmz
  
−
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.
+
# Libera pacotes de fluxos estabelecidos
 +
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
  
−
Obs: quem quiser fazer o exercício com o [[Netkit]] pode usar o seguinte modelo para a rede:
+
# desvia o processamento das regras para outras chains,
 +
# dependendo de onde vem ou para onde vai cada pacote.
 +
# Isto serve para evitar ter que verificar muitas regras ...
 +
iptables -A FORWARD -i eth2 -j vindo_da_rede_interna
 +
iptables -A FORWARD -i eth1 -j vindo_da_dmz
 +
iptables -A FORWARD -o eth1 -j indo_para_dmz
  
−
<syntaxhighlight lang=text>
+
# registra todos os pacotes bloqueados
−
global[compact]=1
+
iptables -A FORWARD -j LOG
−
dmz1[type]=generic
+
iptables -A INPUT -j LOG
−
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
+
# Bloqueia conexoes para web e smtp na Internet vindos da rede interna
−
# em proximas execucoes da rede virtual. Porém para isso deve-se exportar
+
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 80 -j DROP
−
firewall[preserve]=/root/firewall.sh
+
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 8080 -j DROP
−
</syntaxhighlight>
+
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 443 -j DROP
 +
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 3128 -j DROP
 +
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 25 -j DROP
  
−
{{collapse top|Uma possível solução}}
+
# Libera novos fluxos vindos da rede interna em direcao a Internet
−
<syntaxhighlight lang=bash>
+
iptables -A vindo_da_rede_interna -o eth0 -m state --state NEW -j ACCEPT
−
# bloqueia tudo por default
 
−
iptables -P INPUT DROP
 
−
iptables -P FORWARD DROP
 
  
−
# redireciona os ports smtp, dns, ssh, http e https para os servidores
+
# Libera conexoes smtp e consultas DNS vindas da DMZ
−
# da DMZ
+
iptables -A vindo_da_dmz -o eth0 -p tcp --dport 25 -s 10.0.0.2 -m state --state NEW -j ACCEPT
−
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2  
+
iptables -A vindo_da_dmz -o eth0 -p udp --dport 53 -s 10.0.0.2 -m state --state NEW -j ACCEPT
−
iptables -t nat -A PREROUTING -i eth0 -p udp -m udp --dport 53 -j DNAT --to-destination 10.0.0.2
 
−
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 10.0.0.2:22
 
−
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 2200 -j DNAT --to-destination 10.0.0.1:22
 
−
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80
 
−
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.1
 
  
−
# Faz NAT de tudo que sai em direcao a Internet
+
# Libera ports smtp,ssh,dns,http e https para os servidores da DMZ
−
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
+
iptables -A indo_para_dmz -p tcp --dport 25 -d 10.0.0.2 -m state --state NEW -j ACCEPT
 +
iptables -A indo_para_dmz -p tcp --dport 22 -d 10.0.0.2 -m state --state NEW -j ACCEPT
 +
iptables -A indo_para_dmz -p udp --dport 53 -d 10.0.0.2 -m state --state NEW -j ACCEPT
 +
iptables -A indo_para_dmz -p tcp --dport 22 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 +
iptables -A indo_para_dmz -p tcp --dport 80 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 +
iptables -A indo_para_dmz -p tcp --dport 443 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 +
</syntaxhighlight>
 +
{{collapse bottom}}
  
−
# Libera pacotes de fluxos estabelecidos
+
== E como são outros filtros de pacotes ? ==
−
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
 
  
−
# Libera novos fluxos vindos da rede interna em direcao a Internet
+
Existem outros filtros de pacotes, os quais são usados em outros sistemas operacionais. A lógica de suas regras é muito parecida com a usada no ''iptables''. Portanto, se você entendeu bem como funciona o ''iptables'', pode também aprender rapidamente a usá-los. Veja os exemplos abaixo:
−
iptables -A FORWARD -i eth2 -o eth0 -m state --state NEW -j ACCEPT
+
* Regras com iptables: <syntaxhighlight lang=bash>
 +
iptables -P FORWARD DROP
  
−
# Libera ports smtp,ssh,dns,http e https para os servidores da DMZ
+
# Libera fluxos estabelecidos
−
iptables -A FORWARD -p tcp --dport 25 -d 10.0.0.2 -m state --state NEW -j ACCEPT
+
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
−
iptables -A FORWARD -p tcp --dport 22 -d 10.0.0.2 -m state --state NEW -j ACCEPT
 
−
iptables -A FORWARD -p udp --dport 53 -d 10.0.0.2 -m state --state NEW -j ACCEPT
 
−
iptables -A FORWARD -p tcp --dport 22 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 
−
iptables -A FORWARD -p tcp --dport 80 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 
−
iptables -A FORWARD -p tcp --dport 443 -d 10.0.0.1 -m state --state NEW -j ACCEPT  
 
  
−
# registra todos os pacotes bloqueados
+
# Libera acessos vindos da rede interna ao servidor DNS externo
−
iptables -A FORWARD -j LOG
+
iptables -A FORWARD -i eth0 -p udp -d 200.135.37.65 --dport 53 -m state --state NEW -j ACCEPT
−
iptables -A INPUT -j LOG
 
−
</syntaxhighlight>
 
−
{{collapse bottom}}
 
  
−
== Estendendo as regras do firewall ==
 
  
−
Na rede do exercício sobre firewall, algumas novas regras de policiamento de tráfego devem ser implantadas:
+
# Libera acessos vindos da rede interna para Web
−
* '''DMZ:'''
+
iptables -A FORWARD -i eth0 -p tcp --dport 80 -m state --state NEW -j ACCEPT
−
** O servidor SMTP deve poder enviar mensagens para fora.
+
iptables -A FORWARD -i eth0 -p tcp --dport 443 -m state --state NEW -j ACCEPT
−
* '''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).
 
  
−
{{collapse top|Uma possível solução}}
+
</syntaxhighlight>
−
<syntaxhighlight lang=bash>
+
* [http://www.freebsd.org/doc/handbook/firewalls-ipf.html IP Filter (usado no FreeBSD e Solaris)]:<syntaxhighlight lang=bash>
−
# bloqueia tudo por default
+
# Obs: dc0 é a interface de rede interna (nomenclatura do FreeBSD)
−
iptables -P INPUT DROP
+
# Obs 2: no IP Filter, o próprio filtro bloqueia tudo por default ...
−
iptables -P FORWARD DROP
 
  
−
# redireciona os ports smtp, dns, ssh, http e https para os servidores
+
# Libera acessos vindos da rede interna ao servidor DNS externo
−
# da DMZ
+
pass in quick on dc0 proto udp from any to 200.135.37.65 port = 53 keep state
−
iptables -t nat -A PREROUTING -i eth2 -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2
 
−
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2
 
−
iptables -t nat -A PREROUTING -i eth0 -p udp -m udp --dport 53 -j DNAT --to-destination 10.0.0.2
 
−
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 10.0.0.2:22
 
−
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 2200 -j DNAT --to-destination 10.0.0.1:22
 
−
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80
 
−
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.1
 
  
−
# Faz NAT de tudo que sai em direcao a Internet
+
# Libera acessos vindos da rede interna para Web
−
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
+
pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state
 +
pass in quick on dc0 proto tcp from any to any port = 443 flags S keep state
 +
</syntaxhighlight>
 +
* [http://www.freebsd.org/doc/handbook/firewalls-ipfw.html IPFW (usado no FreeBSD)]:<syntaxhighlight lang=bash>
 +
# Libera fluxos estabelecidos
 +
ipfw -q add 10 check-state
  
−
# libera fluxos já estabelecidos para o firewall
+
# Libera acessos vindos da rede interna ao servidor DNS externo
−
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
+
ipfw -q add 20 allow udp from any to 200.135.37.65 53 out via dc0 keep-state  
  
−
# libera acesso vindo da rede interna ao proxy http no firewall.
+
# Libera acessos vindos da rede interna a servidores web externos
−
iptables -A INPUT -i eth2 -p tcp --dport 3128 -m state --state NEW -j ACCEPT
+
ipfw -q add 30 allow tcp from any to any 80 in via dc0 setup keep-state  
 +
ipfw -q add 40 allow tcp from any to any 443 in via dc0 setup keep-state  
 +
</syntaxhighlight>
 +
* [http://www.openbsd.org/faq/pf/filter.html PF (usado no OpenBSD e FreeBSD)]: <syntaxhighlight lang=bash>
 +
# Obs: dc1 é a interface externa
 +
# Obs2: este filtro de pacotes é stateful por default
  
−
# libera acesso vindo de qualquer lugar a ssh no firewall.
+
# opções globais
−
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
+
set block-policy return
 +
set loginterface egress
 +
set skip on lo
  
−
# libera novos fluxos e fluxos já estabelecidos vindos do firewall
+
# bloqueia todo tráfego entrante por default, e libera o sainte
−
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
+
block in log on dc1
−
iptables -A OUTPUT -m state --state NEW -j ACCEPT
+
pass out quick on dc0
  
−
# Libera pacotes de fluxos estabelecidos
+
# Preciso liberar o que vem de dentro (quando entra no firewal ... na saída
−
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
+
# será feita nova verificação).
 +
pass in quick on dc0
  
−
# Bloqueia conexoes para web e smtp na Internet vindos da rede interna
+
# Libera ICMP (ping)
−
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 80 -j DROP
+
pass out quick on dc1 inet proto icmp all icmp-type echoreq
−
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 8080 -j DROP
 
−
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 443 -j DROP
 
−
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 3128 -j DROP
 
−
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 25 -j DROP
 
  
−
# Libera novos fluxos vindos da rede interna em direcao a Internet
+
# Libera dns e web vindos da rede interna
−
iptables -A FORWARD -i eth2 -o eth0 -m state --state NEW -j ACCEPT
+
pass out quick on dc1 proto udp from any to 200.135.37.65 port 53
 +
pass out quick on dc1 proto tcp from any to any port 80
 +
pass out quick on dc1 proto tcp from any to any port 443
 +
</syntaxhighlight>
 +
 
 +
 
 +
<!-- == Documento a ser entregue ==
  
−
# Libera conexoes smtp e consultas DNS vindas da DMZ
+
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.
−
iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 25 -s 10.0.0.2 -m state --state NEW -j ACCEPT
+
-->
−
iptables -A FORWARD -i eth1 -o eth0 -p udp --dport 53 -s 10.0.0.2 -m state --state NEW -j ACCEPT
+
 
 +
<!-- == Lista de exercícios ==
  
−
# Libera ports smtp,ssh,dns,http e https para os servidores da DMZ
+
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:
−
iptables -A FORWARD -p tcp --dport 25 -d 10.0.0.2 -m state --state NEW -j ACCEPT
+
* '''Exercícios de fixação:''' todos
−
iptables -A FORWARD -p tcp --dport 22 -d 10.0.0.2 -m state --state NEW -j ACCEPT
+
* '''Problemas:''' 1, 3, 4, 5, 7, 9, 10, 11, 20, 21, 22, 23, 24, 25, 26, 27, 28
−
iptables -A FORWARD -p udp --dport 53 -d 10.0.0.2 -m state --state NEW -j ACCEPT
+
-->
−
iptables -A FORWARD -p tcp --dport 22 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 
−
iptables -A FORWARD -p tcp --dport 80 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 
−
iptables -A FORWARD -p tcp --dport 443 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 
  
−
# registra todos os pacotes bloqueados
+
== Projeto final ==
−
iptables -A FORWARD -j LOG
 
−
iptables -A INPUT -j LOG
 
−
</syntaxhighlight>
 
−
{{collapse bottom}}
 
  
−
{{collapse top|Outra possível solução, e que explora a hierarquização de chains}}
+
O projeto final de RMU trata de adicionar firewalls e mecanismos de QoS à [[RMU-2013-2#Trabalho_2|rede do projeto 2]]. Essa rede sofreu uma pequena modificação, com os links das redes dos clientes sendo implantados com ADSL (na verdade, links PPPoE com taxas de downstream de 1 Mbps e upstream de 400 kbps). Outra pequena alteração foi o acréscimo dos firewalls dos provedores (''fw1'' e ''fw2''), e a inclusão de um servidor web na LAN do provedor 1. Por fim, para reduzir o tamanho da rede foi retirado o cliente C (que continha o ''pbxc'' e ''fone5'').
−
<syntaxhighlight lang=bash>
 
−
# bloqueia tudo por default
 
−
iptables -P INPUT DROP
 
−
iptables -P FORWARD DROP
 
  
−
# Cria uma nova chain na tabela nat, para conter as regras que
 
−
# se aplicam a pacotes vindos da Internet.
 
−
iptables -t nat -N vindo_de_fora
 
  
−
# redireciona os ports smtp, dns, ssh, http e https para os servidores
+
[[imagem:Trab3-2013-2.png|600px]]
−
# da DMZ
+
<br>''A rede com os PBX, telefones IP, e links PPPoE''
−
iptables -t nat -A PREROUTING -i eth2 -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2  
 
−
iptables -t nat -A PREROUTING -i eth0 -j vindo_de_fora
 
−
iptables -t nat -A vindo_de_fora -p udp -m udp --dport 53 -j DNAT --to-destination 10.0.0.2
 
−
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2
 
−
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 2201 -j DNAT --to-destination 10.0.0.2:22
 
−
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 2200 -j DNAT --to-destination 10.0.0.1:22
 
−
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80
 
−
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.1
 
  
−
# Faz NAT de tudo que sai em direcao a Internet
 
−
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
 
  
−
# libera fluxos já estabelecidos para o firewall
+
As modificações a serem feitas nessa rede devem atender o seguinte:
−
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
+
* ''Os diferentes tipos de tráfego devem ter seus requisitos de QoS atendidos:''
 +
* ''As comunicações dos usuários devem ser policiadas:''
  
−
# libera acesso vindo da rede interna ao proxy http no firewall.
 
−
iptables -A INPUT -i eth2 -p tcp --dport 3128 -m state --state NEW -j ACCEPT
 
  
−
# libera acesso vindo de qualquer lugar a ssh no firewall.
+
A turma deve se dividir em equipes de até 03 alunos.
−
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
+
* '''Prazo de entrega: 16/12'''
  
−
# libera novos fluxos e fluxos já estabelecidos vindos do firewall
+
== Detalhamento ==
−
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
 
−
iptables -A OUTPUT -m state --state NEW -j ACCEPT
 
  
−
iptables -N vindo_da_rede_interna
+
O trabalho será feito usando o [[Netkit]] (versão 1.97 ou superior).
−
iptables -N vindo_da_dmz
+
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/trab3-2013-2.netkit Arquivo de projeto do Netkit para o trabalho]
−
iptables -N indo_para_dmz
+
* '''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.
 +
* '''Obs 2:''' na versão 1.97 do Netkit, o Asterisk pode ser iniciado automaticamente no boot. Isso foi explorado na configuração do projeto. Além do Asterisk, são iniciados automaticamente os servidores SSH nos firewalls, e o Apache em ''web''.
  
−
# Libera pacotes de fluxos estabelecidos
 
−
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
 
  
−
# desvia o processamento das regras para outras chains,
+
'''Requisitos:'''
−
# dependendo de onde vem ou para onde vai cada pacote.
+
* As redes dos clientes usam NAT para acessar a rede WAN. A rede do provedor usa IPs públicos.
−
# Isto serve para evitar ter que verificar muitas regras ...
+
* Por default, tudo está bloqueado.
−
iptables -A FORWARD -i eth2 -j vindo_da_rede_interna
+
* Chamadas VoIP têm prioridade a todos demais tipos de tráfego, porém limitadas a até duas chamadas VoIP simultâneas.
−
iptables -A FORWARD -i eth1 -j vindo_da_dmz
+
* O servidor ''web'' do provedor pode ser acessado da Internet para serviço Web (protocolos HTTP e HTTPS nas portas padrões).
−
iptables -A FORWARD -o eth1 -j indo_para_dmz
+
* Firewalls dos clientes (r1 e r2) e dos provedores (''fw1'' e ''fw2'') podem ser acessados da Internet com SSH.
−
 
+
* 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.
−
# registra todos os pacotes bloqueados
+
* Os firewalls rodam servidores DNS, e assim os usuários das redes da empresa somente podem fazer consultas DNS nos Firewalls.
−
iptables -A FORWARD -j LOG
+
* A implantação de um domínio Diffserv é '''opcional''' ... mas isso possibilitaria ter QoS de forma mais consistente na rede.
−
iptables -A INPUT -j LOG
 
−
 
 
−
# Bloqueia conexoes para web e smtp na Internet vindos da rede interna
 
−
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 80 -j DROP
 
−
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 8080 -j DROP
 
−
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 443 -j DROP
 
−
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 3128 -j DROP
 
−
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 25 -j DROP
 
−
 
 
−
# Libera novos fluxos vindos da rede interna em direcao a Internet
 
−
iptables -A vindo_da_rede_interna -o eth0 -m state --state NEW -j ACCEPT
 
−
 
 
−
# Libera conexoes smtp e consultas DNS vindas da DMZ
 
−
iptables -A vindo_da_dmz -o eth0 -p tcp --dport 25 -s 10.0.0.2 -m state --state NEW -j ACCEPT
 
−
iptables -A vindo_da_dmz -o eth0 -p udp --dport 53 -s 10.0.0.2 -m state --state NEW -j ACCEPT
 
−
 
 
−
# Libera ports smtp,ssh,dns,http e https para os servidores da DMZ
 
−
iptables -A indo_para_dmz -p tcp --dport 25 -d 10.0.0.2 -m state --state NEW -j ACCEPT
 
−
iptables -A indo_para_dmz -p tcp --dport 22 -d 10.0.0.2 -m state --state NEW -j ACCEPT
 
−
iptables -A indo_para_dmz -p udp --dport 53 -d 10.0.0.2 -m state --state NEW -j ACCEPT
 
−
iptables -A indo_para_dmz -p tcp --dport 22 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 
−
iptables -A indo_para_dmz -p tcp --dport 80 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 
−
iptables -A indo_para_dmz -p tcp --dport 443 -d 10.0.0.1 -m state --state NEW -j ACCEPT
 
−
</syntaxhighlight>
 
−
{{collapse bottom}}
 
−
 
 
−
== E como são outros filtros de pacotes ? ==
 
−
 
 
−
Existem outros filtros de pacotes, os quais são usados em outros sistemas operacionais. A lógica de suas regras é muito parecida com a usada no ''iptables''. Portanto, se você entendeu bem como funciona o ''iptables'', pode também aprender rapidamente a usá-los. Veja os exemplos abaixo:
 
−
* Regras com iptables: <syntaxhighlight lang=bash>
 
−
iptables -P FORWARD DROP
 
−
 
 
−
# Libera fluxos estabelecidos
 
−
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
 
−
 
 
−
# Libera acessos vindos da rede interna ao servidor DNS externo
 
−
iptables -A FORWARD -i eth0 -p udp -d 200.135.37.65 --dport 53 -m state --state NEW -j ACCEPT
 
−
 
 
−
 
 
−
# Libera acessos vindos da rede interna para Web
 
−
iptables -A FORWARD -i eth0 -p tcp --dport 80 -m state --state NEW -j ACCEPT
 
−
iptables -A FORWARD -i eth0 -p tcp --dport 443 -m state --state NEW -j ACCEPT
 
−
 
 
−
</syntaxhighlight>
 
−
* [http://www.freebsd.org/doc/handbook/firewalls-ipf.html IP Filter (usado no FreeBSD e Solaris)]:<syntaxhighlight lang=bash>
 
−
# Obs: dc0 é a interface de rede interna (nomenclatura do FreeBSD)
 
−
# Obs 2: no IP Filter, o próprio filtro bloqueia tudo por default ...
 
−
 
 
−
# Libera acessos vindos da rede interna ao servidor DNS externo
 
−
pass in quick on dc0 proto udp from any to 200.135.37.65 port = 53 keep state
 
−
 
 
−
# Libera acessos vindos da rede interna para Web
 
−
pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state
 
−
pass in quick on dc0 proto tcp from any to any port = 443 flags S keep state
 
−
</syntaxhighlight>
 
−
* [http://www.freebsd.org/doc/handbook/firewalls-ipfw.html IPFW (usado no FreeBSD)]:<syntaxhighlight lang=bash>
 
−
# Libera fluxos estabelecidos
 
−
ipfw -q add 10 check-state
 
−
 
 
−
# Libera acessos vindos da rede interna ao servidor DNS externo
 
−
ipfw -q add 20 allow udp from any to 200.135.37.65 53 out via dc0 keep-state
 
−
 
 
−
# Libera acessos vindos da rede interna a servidores web externos
 
−
ipfw -q add 30 allow tcp from any to any 80 in via dc0 setup keep-state
 
−
ipfw -q add 40 allow tcp from any to any 443 in via dc0 setup keep-state
 
−
</syntaxhighlight>
 
−
* [http://www.openbsd.org/faq/pf/filter.html PF (usado no OpenBSD e FreeBSD)]: <syntaxhighlight lang=bash>
 
−
# Obs: dc1 é a interface externa
 
−
# Obs2: este filtro de pacotes é stateful por default
 
−
 
 
−
# opções globais
 
−
set block-policy return
 
−
set loginterface egress
 
−
set skip on lo
 
−
 
 
−
# bloqueia todo tráfego entrante por default, e libera o sainte
 
−
block in log on dc1
 
−
pass out quick on dc0
 
−
 
 
−
# Preciso liberar o que vem de dentro (quando entra no firewal ... na saída
 
−
# será feita nova verificação).
 
−
pass in quick on dc0
 
−
 
 
−
# Libera ICMP (ping)
 
−
pass out quick on dc1 inet proto icmp all icmp-type echoreq
 
−
 
 
−
# Libera dns e web vindos da rede interna
 
−
pass out quick on dc1 proto udp from any to 200.135.37.65 port 53
 
−
pass out quick on dc1 proto tcp from any to any port 80
 
−
pass out quick on dc1 proto tcp from any to any port 443
 
−
</syntaxhighlight>
 
  
 +
=== NAT e Asterisk ===
  
−
<!-- == Documento a ser entregue ==
+
O NAT exige algumas configurações especiais para o Asterisk, do contrário as chamadas não funcionam (principalmente o que diz respeito ao RTP).
  
−
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.
+
* [[RMU-2013-2#Implanta.C3.A7.C3.A3o_de_uma_infraestrutura_VoIP|Nat e Asterisk]]
−
-->
 
  
−
<!-- == Lista de exercícios ==
+
= 13/12: Avaliação 3 =
−
 
 
−
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
 
−
-->
 
−
 
 
−
== Projeto final ==
 
−
 
 
−
O projeto final de RMU trata de adicionar firewalls e mecanismos de QoS à [[RMU-2013-1#15.2F05:_Trabalho_1|rede do projeto 1]]. Essa rede sofreu uma pequena modificação, com os links das redes dos clientes sendo implantados com ADSL (na verdade, links PPPoE com taxas de downstream de 1 Mbps e upstream de 400 kbps). Outra pequena alteração foi o acréscimo de um roteador (''r4'') entre a LAN do provedor e a rede WAN, e a inclusão de um servidor web na LAN do provedor. Por fim, para reduzir o tamanho da rede foi retirado o cliente C (que continha o ''pbxc'', ''fone5'' e ''fone6'').
 
−
 
 
−
 
 
−
[[imagem:Rmu-Trab2-2013-1.png|600px]]
 
−
<br>''A rede com os PBX, telefones IP, e links PPPoE''
 
−
 
 
−
 
 
−
As modificações a serem feitas nessa rede devem atender o seguinte:
 
−
* ''Os diferentes tipos de tráfego devem ter seus requisitos de QoS atendidos:''
 
−
* ''As comunicações dos usuários devem ser policiadas:''
 
−
 
 
−
 
 
−
A turma deve se dividir em equipes de até 03 alunos.
 
−
* '''Prazo de entrega: 31/07'''
 
−
 
 
−
== Detalhamento ==
 
−
 
 
−
O trabalho será feito usando o [[Netkit]] (versão 1.95 ou superior).
 
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/trab2-2013-1.netkit Arquivo de projeto do Netkit para o trabalho]
 
−
* '''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.
 
−
* '''Obs 2:''' na versão 1.95 do Netkit, o Asterisk pode ser iniciado automaticamente no boot. Isso foi explorado na configuração do projeto. Além do Asterisk, são iniciados automaticamente os servidores SSH em ''r1'', ''r2'' e ''r4'', e o Apache em ''web''.
 
−
 
 
−
 
 
−
'''Requisitos:'''
 
−
* As redes dos clientes usam NAT para acessar a rede WAN. A rede do provedor usa IPs públicos.
 
−
* 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.
 
−
* O servidor ''web'' do provedor pode ser acessado da Internet para serviço Web (protocolos HTTP e HTTPS nas portas padrões).
 
−
* Firewalls dos clientes e do provedor (''r1'', ''r2'' e ''r4'') podem ser acessados da Internet com SSH.
 
−
* 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.
 
−
 
 
−
= 25/07: Avaliação 3 =
 
  
 
* Disciplinas de filas
 
* Disciplinas de filas
Linha 4 048: Linha 4 141:
 
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/ex-prova1-2012-1.pdf Questões usadas em 2012-1]
 
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/ex-prova1-2012-1.pdf Questões usadas em 2012-1]
 
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/prova2e3-2012-2.pdf Questões usadas em 2012-2]
 
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/prova2e3-2012-2.pdf Questões usadas em 2012-2]
 +
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova2-rmu-2013-1-corrigida.pdf Prova de 2013-1 corrigida]
  
−
= 31/07: Apresentação do projeto =
+
= 18/12: Recuperação =
−
 
 
−
No laboratório ...
 
−
 
 
−
= 01/08: Recuperação =
 
  
−
* [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova2-rmu-2013-1-corrigida.pdf Prova 2 corrigida]
+
<!-- * [http://tele.sj.ifsc.edu.br/~msobral/rmu/provas/prova2-rmu-2013-1-corrigida.pdf Prova 2 corrigida] -->

Edição atual tal como às 15h27min de 3 de fevereiro de 2015

Redes Multimidia: Diário de Aula 2013-2

Professor: Marcelo Maia Sobral
Lista de email (forum): rmu-ifsc@googlegroups.com
Encontros: 4a feira/13:30, 6a feira/13:30
Atendimento paralelo: 4a feira 10:30-11:30 ou 15:30-16:30

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 Trabalho Servidor de video Trabalho VoIP Trabalho Firewalls FINAL
Aliny D+/C C A B
ura inacessível		 C C
Francisco C+ B+ A B
numeração dos contatos
pbxa não permite chamar contatos locais		 A B
Leandro C+ C+ A B
numeração dos contatos
pbxa não permite chamar contatos locais		 C C
Liamari D/D D/D D
alguns telefones não registram
pbxa desvia chamadas para ura
pbxa não encaminha para outros pbx		 D D
Maicky D+/C C A B
numeração dos contatos
pbxa não permite chamar contatos locais		 C C
Maycon B C+ A A A A
Nicole C C A A A C

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

Softwares

16/08: 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:

Mmn example2.png Mmn-intro.png
Videophone.jpg CaseStudy RealTimeTelemedicine Network Image.jpeg


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 ?

TAREFA: leitura da semana

Leiam este texto introdutório sobre redes multimedia e suas aplicações, e preparem-se para apresentá-lo na próxima aula (21/08). A apresentação deverá durar de 10 a 15 minutos e ser composta de:

  • Um resumo sobre os conceitos-chaves contidos no texto
  • Alguns slides (não mais que 10) para auxiliar a explicação desses conceitos chaves.
    • Não carregue os slides de texto ! Priorize o uso de figuras, diagramas e frases curtas para enunciar cada ideia apresentada.

Durante a apresentação qualquer aluno ou o professor poderão fazer apartes. Em particular, o professor pode pedir a outro aluno para explicar o que entendeu sobre determinada informação apresentada.

Um aluno será sorteado para fazer sua apresentação. Caso não a tenha preparado, receberá um conceito negativo que influenciará seu conceito final (isso vale também para alunos sorteados que tiverem faltado). O sorteio será realizado até que um aluno faça a apresentação.

21/08: 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 esta imagem para seu computador, e recorte uma parte com dimensões 128x128 pixels (use o gimp).

1.1) Qual o tamanho dessa imagem no formato BMP com 24 bpp ?

1.2) Qual o tamanho dessa imagem no formato PNG ? E no formato JPG ?

1.3) Crie uma nova imagem com dimensões 128x128 pixels e que seja toda preta, e determina seu tamanho nos formatos BMP com 24 bpp, PNG e JPG.

1.4) O que se pode concluir quanto à representação digital das imagens ?

2) Copie este arquivo compactado para seu computador, e em seguida descompacte-o. Note que ele contém um certo número de arquivos de imagem em formato JPG (experimente visualizar alguns deles).

2.1) Crie um video a partir dessas imagens. Esse video estará no formato MPJG (Motion JPG), que nada mais é que as imagens sequencializadas. 

cd figs
mencoder mf://\*.jpg -fps 10 -ovc copy -o video.avi

2.2) Veja o tamanho do arquivo de video, e compare-o com o tamanho total das imagens. Em seguida, reproduza-o com vlc ou mplayer.

2.3) Recodifique o seu arquivo de video usando o codec XVID: 

mencoder -o video2.avi -ovc xvid -xvidencopts bitrate=1024 -oac copy video.avi

... e observe o tamanho do arquivo de video resultante. Em seguida reproduza-o com vlc ou mplayer. Como você o compara com o video gerado no item 2.2 ?

3) 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.

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

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

5) 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.

6) 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.

23/08: 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:

  • 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
  • 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

A transmissão de dados multimidia está sujeita a alguns fatores, destacando-se:

  • Banda disponível: cada tipo de transmissão demanda uma certa banda mínima (ver o exemplo dos videos gerados na aula anterior, que demandam em torno de 250 kbps). A banda requerida depende do codec, podendo mesmo ser variável (ver figura abaixo). Se a banda disponível na rede não for suficiente, a reprodução dos dados transmitidos não será possível (quer dizer, a reprodução contínua simultânea ao recebimento dos dados).
    Rt-transmission.png
  • Atrasos fim-a-fim: alguns tipos de transmissão são mais sensíveis a atrasos fim-a-fim, como por exemplo conversações VoIP, porém todas transmissões de dados multimidia apresentam pouca tolerância a variações de atraso. A variação de atraso excessiva causa a perda de sincronismo entre a transmissão e a recepção, impedindo a reprodução contínua dos dados recebidos.

Componentes do atraso fim-a-fim

O atraso fim-a-fim, contado portanto desde a origem de um pacote até seu destino, se compõe de um conjunto de tempos despendidos ao longo de sua transmissão. Alguns desses tempos são constantes, porém outros são variáveis.

Atraso Descrição Tipo Expressão
(F: tamanho de um pacote em bytes,
B: taxa de bits do link)
Transmissão Tempo entre o início da saída do 1o bit até a saída do último bit de um pacote pela interface de rede. Depende basicamente da taxa de bits do link onde se dá a transmissão. Variável (depende do tamanho do pacote)
Propagação Tempo entre a saída do 1o bit de um pacote da interface de rede do equipamento transmissor, e sua chegada na interface de rede do equipamento receptor. Depende basicamente da latência do meio de transmissão. Constante
Processamento Tempo entre a recepção de um pacote e a ação a ser feita sobre ele dentro de um equipamento de rede (seja encaminhá-lo por outro link, ou entregá-lo a uma aplicação que o consumirá) Usualmente desprezível
Enfileiramento Tempo de espera de um pacote na fila de saída de uma interface de rede por onde deve ser transmitido. Depende de quantos pacotes (e quantos bytes) estão na sua frente nessa fila. Variável


No exemplo abaixo, os links LAN (link1, link2, link7 e link8) possuem taxa de 1 Gbps, e os links WAN (demais links) possuem taxa de 10 Mbps. As filas dos roteadores podem conter até 100 pacotes de 1500 bytes (tamanho máximo de pacote). Os links WAN possuem latência de 2 ms (a dos links LAN é desprezível). Sendo assim, calcular o atraso mínimo e máximo que cada pacote pode sofrer entre sua saída do servidor de video e sua chegada no reprodutor. Os pacotes de vídeo têm tamanho de 1500 bytes:

Componentes-atraso.png

Atrasos de transmissão nos links WAN:
Atrasos de transmissão nos links LAN:
Atraso de enfileiramento em roteador: melhor caso
(fila vazia)
Atraso de enfileiramento em roteador: pior caso
(fila cheia):

O menor atraso pode ser calculado assim:


... e o maior atraso possível é:

Com isso, uma transmissão de video nessa rede está sujeita a atrasos máximo de cerca de 492 ms por pacote, e variação de atraso de até . Note-se que, nessa rede, a variação de atraso se deve essencialmente a atrasos de enfileiramento nos roteadores. Em outras redes pode haver fatores adicionais para variações de atraso: perdas de pacotes por erros de transmissão ou congestionamento, priorização de pacotes, e até o controle de congestionamento TCP (se esse protocolo for usado para a transmissão).

O exemplo acima diz respeito a uma pequena rede com bons links WAN e pequeno número de saltos (roteadores intermediários) entre origem e destino. Em um cenário mais realista, como um usuário doméstico acessando videos no Youtube, a situação pode ser bem pior. Para fins de comparação, da rede da escola até o Youtube foram contados 9 saltos, e de casa se contaram 8 saltos (o caso do Youtube é um pouco mais complicado, pois sua infraestrutura é baseada em um tipo de CDN).

Se cada pacote está sujeito a um atraso variável, o reprodutor de video no receptor precisa de algum mecanismo para compensar essas variações e apresentar o video de forma contínua. O mesmo raciocínio vale para transmissões de audio.

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.

Rt-traffic.png
Atrasos devido a transmissão


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.

PROJETO 1: Um serviço de compartilhamento de video

O projeto 1 trata da implantação e demonstração de um sistema de compartilhamento de video semelhante ao Youtube (conhecido como CMS - Content Management System). Tal serviço deve possibilitar:

  • A visualização de videos via web
  • A publicação de videos por usuários cadastrados
  • A reprodução de músicas via web (opcional)
  • A publicação de músicas por usuários cadastrados (opcional)


A implantação do serviço deve ser feita em um servidor da escola. Há um servidor disponibilizado para cada equipe. Pode ser usado qualquer software para CMS, ficando ao gosto de cada equipe. Algumas opções são:


Equipe Alunos Servidor URL
Equipe 1 Nicole, Francisco equipe1.rmu.sj.ifsc.edu.br http://equipe1.rmu.sj.ifsc.edu.br/
Equipe 2 Leandro,Maicky equipe2.rmu.sj.ifsc.edu.br http://equipe2.rmu.sj.ifsc.edu.br/
Equipe 3 Maycon,Aliny equipe3.rmu.sj.ifsc.edu.br http://equipe3.rmu.sj.ifsc.edu.br/
Equipe 4 Liamari equipe4.rmu.sj.ifsc.edu.br http://equipe4.rmu.sj.ifsc.edu.br/


Produto a entregar: até 04/09

  • Cada equipe deve demonstrar o funcionamento do seu servidor de video. Isso inclui fornecer uma conta ao professor para ele publicar videos de teste.
  • Deve ser entregue um relatório descrevendo:
    • Como instalar o serviço de video.
    • Os requisitos (outros softwares) para que o serviço seja instalado.
    • Os formatos de video suportados (codecs e containers).
    • Uma breve descrição de como funciona a transmissão do video: protocolos usados, tipo de reprodutor de video, funcionalidades suportadas (avançar, retroceder, pausa, seleção de qualidade de video, videos online ou armazenados, ...).

TAREFA: IPTV

Faça uma pesquisa sobre IPTV (IP Television), mostrando:

  • o que esse tipo de serviço oferece.
  • qual a arquitetura do serviço, incluindo como pode ser estruturada a rede do provedor do serviço.
  • quais os protocolos envolvidos, e de que modo eles operam para a distribuição da midia.

IMPORTANTE: Na aula de 27/08 sortearei um aluno para que apresente seus trabalho.

Sobre distribuição P2P

28/08: Transmissão de dados multimidia

Estratégias para abrandar a perda de mensagens

Reprodução de mensagens perdidas inadequada para aplicações interativas

  • Mensagens que realmente não chegaram
  • Mensagens que chegaram após instante de reprodução


Técnicas para abrandar a perda de mensagens e preservar uma boa (?!) qualidade de áudio

  • Correção antecipada de erros (FEC - Forward Error Correction)
  • Intercalação

Correção antecipada de erros

Emissor envia dados redundantes em suas mensagens, também conhecidos como um código de correção de erro.

Exemplo 1: envio de uma mensagem redundante para cada grupo de n mensagens. A mensagem redundante é calculada fazendo XOR das demais mensagens do grupo.

  • Tolera a perda de 1 mensagem
  • Aumento de banda de 1/n

Rmu-fec.png
Uso de mensagem redundante com XOR


Exemplo 2: envio de fluxos redundantes de diferentes qualidades.

  • Pode-se enviar um fluxo de qualidade inferior junto com o fluxo principal.

Intercalação

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.

No exemplo abaixo, cada unidade de áudio tem 5 ms, e cada mensagem contém quatro unidades (totalizando 20 ms).


Rmu-intercalacao.png

Atividade

Pesquise sobre o uso de técnicas de abrandamento de perdas de mensagens em diferentes tipos de transmissão de midia: VoIP, video, radio on-line, ...

TAREFA: pesquisa sobre modelos e mecanismos de distribuição de midia

Faça uma breve pesquisa sobre sistemas de distribuição de conteúdo multimidia na Internet (ex: CDN, P2P, ...), apresentando suas características e exemplos de sistemas que os implementem. Em seguida, pesquise também sobre ao menos dois mecanismos 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 ?
  • Prazo de entrega da pesquisa por email: 04/09.
  • Na aula de 04/09, será sorteado um aluno para apresentar sua pesquisa.

Lista de exercícios

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

Atividade

Concluir (ou iniciar) o sistema de distribuição de video do Projeto 1.

30/08: Introdução a Voz sobre IP (VoIP)


VoIP: transmissão de voz usando protocolos da arquitetura TCP/IP, com o objetivo de estabelecer chamadas semelhantes a chamadas telefônicas. Alguns exemplos de aplicações ou padrões VoIP são:

Fone-call.png

Uma chamada VoIP entre dois telefones IP é feita através da rede de dados.


A realização de chamadas VoIP implica a necessidade de alguns mecanismos:

  • Sinalização: deve haver alguma forma de um usuário iniciar uma chamada para outro usuário, de forma parecida com uma chamada telefônica convencional. A sinalização é responsável por possibilitar que um usuário convide outro para o estabelecimento de uma chamada, e para notificar sobre sua aceitação ou não. Além disso, a sinalização deve participar da definição sobre as características da chamada, tais como o codec de áudio.
  • Transmissão de midia: a voz precisa ser digitalizada com algum codec então transmitida entre os participantes da chamada. O transporte da voz digitalizada implica o uso protocolos capazes de encapsulá-la e de atender ou dar subsídios ao atendimento de seus requisitos de qualidade de serviço (atrasos fim-a-fim e variação de atraso, taxa de perdas).

Em RMU será estudado o modelo SIP para VoIP, o qual se compõe de um conjunto de padrões abertos para tratar dos vários aspectos envolvidos na realização de chamadas. Esse modelo, como diz seu nome, tem como principal elemento o protocolo de sinalização SIP (Session Initiation Protocol).

O protocolo SIP

O protocolo SIP segue um modelo P2P (peer-to-peer), em que dois ou mais participantes, chamados de agentes, trocam mensagens com a finalidade de estabelecerem algum tipo de sessão (de voz no nosso caso, mas pode ser de video, mensagem instantânea, ou algum outro tipo de serviço). Assim, cada agente em uma sessão SIP se comporta tanto como cliente (quando envia requisições SIP) quanto servidor (quando responde a requisições SIP). A parte que inicia requisições se chama UAC (User Agent Client), e a que responde requisições é denominada UAS (User Agent Server), estando ambas implementadas nos telefones IP e similares.

Uma sessão SIP envolve a interação entre duas entidades lógicas, que no caso de chamadas VoIP são por vezes chamadas simplesmente de usuários. A diferença entre entidade lógica e agente é que a primeira é o usuário (recurso) que inicia ou recebe chamadas, e o segundo é a aplicação que contém os mecanismos para efetuar e receber chamadas - pense que a entidade seria uma pessoa, e o agente o aparelho telefônico em uma chamada telefônica convencional. Cada entidade é identificada por uma URI (Uniform Resource Indicator) SIP, semelhante a um número de telefone. Além de identificar uma entidade lógica, a informação em uma URI SIP indica a forma com que essa entidade deve ser contatada via SIP. Exemplos de URI SIP seguem abaixo: 

# Uma URI simples, tipicamente usada em mensagens INVITE (que iniciam sessões SIP)
sip:1234@biloxi.example.com

# Uma URI mais elaborada, tipicamente usada em alguns cabeçalhos SIP (ex: Contact ou Refer-to)
sip:joseph.fourier@transform.org:5060;transport=udp;user=ip;method=INVITE;ttl=1;
maddr=240.101.102.103?Subject=FFT

As comunicações SIP seguem uma hierarquia, cujos níveis são:

  • Mensagens: mensagens de texto individuais trocadas entre agentes.
  • Transação: sequência de mensagens entre dois agentes iniciando com uma requisição e terminando com uma resposta final.
  • Diálogo: uma relação entre dois agentes que persiste por algum tempo, e identificada por um Call-ID.
  • Chamada: composta por todos os diálogos originados por um agente.

Sip-relation.gif
'Mensagens, transações, diálogos e chamadas

Mensagens SIP

O protocolo SIP tem uma estrutura simplificada com mensagens de pedido e resposta, assemelhando-se ao protocolo HTTP. Essas mensagens possuem a seguinte estrutura: 

Linha inicial
Cabeçalho1: valor do cabeçalho 1
Cabeçalho2: valor do cabeçalho 2
...
CabeçalhoN: valor do cabeçalho N
<linha em branco>
corpo da mensagem (opcional)

A diferença básica entre pedidos e respostas SIP está na linha inicial: pedidos contém um método SIP e seus parâmetros, e respostas possuem um código de status junto com um curto texto informativo. Abaixo são mostradas duas mensagens SIP: um pedido e sua respectiva resposta. Nesse exemplo, ambas mensagens não possuem um corpo de mensagem (lembre que isso é opcional):


Sip-example1.png


Pedido: 

REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Content-Length: 0

Resposta: 

SIP/2.0 200 OK
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
 ;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
To: Bob <sips:bob@biloxi.example.com>;tag=37GkEhwl6
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
Content-Length: 0

O pedido exemplificado foi uma mensagem do tipo REGISTER, que é um tipo de método SIP. Um método pode ser entendido como um comando enviado de um participante a outro. A resposta contém o status 200 OK, que significa que o pedido foi atendido com sucesso. Por fim, ambas mensagens contiveram um conjunto de cabeçalhos necessários para caracterizá-las, dentre eles Via, From, To, Call-Id, CSeq, Contact e Content-Length. As tabelas a seguir descrevem resumidamente os principais métodos e cabeçalhos SIP.

Método SIP Descrição
REGISTER Usado por um agente para notificar a rede SIP (outros agentes) sobre sua URI de contato
INVITE Usado para estabelecer sessões entre dois agentes
ACK Confirma respostas finais a requisições INVITE
BYE Termina uma sessão previamente estabelecida
CANCEL Encerra tentativas de chamadas
OPTIONS Consulta um agente sobre suas capacidades

Tabela de métodos SIP (não exaustiva ... apenas os principais métodos)


Cabeçalho SIP Descrição Obrigatoriedade Uso
Via Registra a rota seguida por uma requisição, sendo usado para que respostas sigam o caminho inverso Requisição e resposta Requisição e resposta
To Identifica o destinatário de uma requisição Requisição e resposta Requisição e resposta
From Identifica o originador da requisição Requisição e resposta Requisição e resposta
Call-Id Identifica univocamente uma chamada entre um UAC e um UAS. Requisição e resposta Requisição e resposta
CSeq Numera as requisições de uma mesma chamada de um mesmo UAC Requisição Requisição e resposta
Contact Identifica o originador da requisição ou o recurso requisitado Requisição e resposta
Max-Forwards Máximo número de saltos que a requisição pode atravessar Requisição Requisição
Content-Length Informa a quantidade de bytes do corpo da mensagem Requisição e resposta
Date Informa a data e horário de uma requisição ou resposta Requisição e resposta
Supported Lista uma ou mais opções suportadas por um UAC ou UAS Requisição e resposta
User-Agent Informa sobre o agente (o programa) originador de uma requisição
Allow Informa os métodos SIP aceitos pelo UAS Resposta
Content-type Informa o tipo de conteúdo contido no corpo da mensagem
WWW-Authenticate Informa que o UAC deve se autenticar para o UAS (e como isso deve ser feito) Resposta
Authorization Contém as credenciais para autenticar o UAC para o UAS Requisição

Tabela de cabeçalhos SIP (não exaustiva ... apenas os principais cabeçalhos)

Diagramas de chamadas

Alguns tipos de chamadas VoIP com SIP são recorrentes, estando representadas nas subseções a seguir.

Registro de agente SIP em um proxy SIP

Esta chamada ocorre entre um agente SIP e um servidor de registro SIP (SIP Registar), que está implementado tipicamente em um proxy SIP, um gateway de media, ou um PBX IP (este último incorpora as funções dos dois primeiros com as de um PBX). O registro do agente SIP tem por finalidade fazer com que o servidor de registro SIP conheça a localização do agente (endereço IP e port usado pelo UAS). 

Fone 1                      Proxy SIP ou PBX IP
     |                             |
     |          REGISTER           |
     |---------------------------->|
     |      401 Unauthorized       |
     |<----------------------------|
     |          REGISTER           |
     |---------------------------->|
     |            200 OK           |
     |<----------------------------|
     |                             |

Chamada direta entre dois agentes SIP

Uma chamada direta entre dois agentes envolve uma transação INVITE, em que um agente convida o outro a estabelecer uma sessão SIP com um determinado tipo de media (ex: audio). A chamada é finalizada quando um dos agentes inicia uma transação BYE. 

 Fone 1                    Fone 2
     |                        |
     |       INVITE           |
     |----------------------->|
     |    180 Ringing         |
     |<-----------------------|
     |                        |
     |       200 OK           |
     |<-----------------------|
     |         ACK            |
     |----------------------->|
     |      RTP Media         |
     |<======================>|
     |                        |
     |         BYE            |
     |<-----------------------|
     |       200 OK           |
     |----------------------->|
     |                        |

Chamada entre dois agentes SIP com intermediação de um Proxy SIP

A principal diferença entre este tipo de chamada e o anterior é o uso de um (ou mais) proxy SIP entre os dois agentes. O proxy SIP tem por finalidade ajudar na realização das chamadas, uma vez que usualmente incorpora a função de servidor de registro. Um proxy SIP encaminha chamadas para o agente chamado, ou para outro proxy mais próximo do destino, podendo aplicar regras de controle de acesso quanto a quem pode realizar chamadas para quem. 

Fone 1      Proxy SIP ou PBX IP     Fone 2  
             (directmedia=yes)          
     |                |                |                
     |   INVITE       |                |                
     |--------------->|   INVITE       |                
     |  100 Trying    |--------------->|    
     |<---------------|   100 Trying   |
     |                |<---------------|                
     |                |                |     
     |                |  180 Ringing   |
     |  180 Ringing   |<---------------|                
     |<---------------|                |    
     |                |    200 Ok      |
     |     200 Ok     |<---------------|                
     |<---------------|                |                
     |     ACK        |                |                
     |--------------->|    ACK         |                
     |                |--------------->|    
     |                |                |
     |         RTP Media               |
     |<===============================>|
     |                |                |
     |                |    BYE         |
     |     BYE        |<---------------|                
     |<---------------|                |                
     |     200 Ok     |                |                
     |--------------->|     200 Ok     |                
     |                |--------------->|    
     |                |                |
     |                |                |

Chamada entre dois agentes SIP com intermediação de um gateway de media

Este caso é parecido com o anterior, que usa um proxy SIP. A diferença está na intermediação do fluxo de media, que é feita pelo gateway de media. Isso possibilita que dois agentes estabeleçam uma chamada mesmo usando codecs diferentes, pois o gateway de media fará a tradução entre codecs. 

Fone 1            PBX IP              Fone 2
              (directmedia=no)        
     |                |                |
     |   INVITE       |                |
     |--------------->|   INVITE       |
     |  100 Trying    |--------------->| 
     |<---------------|  100 Trying    |
     |                |<---------------| 
     |                |   180 Ringing  |
     |   180 Ringing  |<---------------|                
     |<---------------|                |      
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |     ACK        |                |
     |--------------->|    ACK         |
     |                |--------------->|
     |    RTP Media   |   RTP Media    |
     |<==============>|<==============>|
     |     BYE        |                |
     |--------------->|    BYE         |
     |                |--------------->|
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |                |                |

Chamada entre dois agentes SIP com intermediação de um gateway de media e uso de re-INVITE

O uso de re-invite possibilita que o fluxo de media seja estabelecido diretamente entre os agentes SIP, caso usem o mesmo codec. Assim, evita-se a carga de processamento envolvida na intermediação pelo gateway de media. Isso é feito com o envio pelo gateway de media (representado abaixo por um PBX IP) de um novo INVITE para cada agente SIP, após a sessão SIP estar estabelecida. Esse novo INVITE contém uma descrição de media (mensagem SDP embutida no corpo da mensagem INVITE) com a localização do outro agente SIP - isso é, seu endereço IP, port UDP para a stream RTP e codec a ser usado. 

Fone 1            PBX IP              Fone 2
              (directmedia=yes)        
     |                |                |
     |   INVITE       |                |
     |--------------->|   INVITE       |
     |  100 Trying    |--------------->| 
     |<---------------|  100 Trying    |
     |                |<---------------| 
     |                |  180 Ringing   |
     |  180 Ringing   |<---------------|                
     |<---------------|                |      
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |     ACK        |                |
     |--------------->|    ACK         |
     |    INVITE      |--------------->|
     |<---------------|   INVITE       |
     |    200 OK      |--------------->|
     |--------------->|    200 OK      |
     |    ACK         |<---------------|
     |--------------->|    ACK         |
     |                |<---------------| 
     |                                 |
     |              RTP Media          |
     |<===============================>|
     |     BYE        |                |
     |--------------->|    BYE         |
     |                |--------------->|
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |                |                |

Atividade 1: Ligação SIP ponto a ponto

O primeiro experimento com uma chamada VoIP envolve estabelecer uma chamada diretamente entre dois softphones. Cada par de alunos deve fazer o seguinte:

  1. Executar o Jitsi (ver em Aplicativos->Internet).
  2. Definir uma conta SIP contendo somente um identificador de usuário (sem a localização).
  3. Um dos alunos deve iniciar uma chamada para o outro aluno, que deve atendê-la.
  4. Experimente falar ao microfone e escutar o som no fone de ouvido.
  5. Encerre a chamada.


A sequência de passos acima estabelece uma chamada VoIP do tipo mais simples possível. Para ver os detalhes da comunicação entre os softphones faça o seguinte:

  1. Execute o wireshark e inicie a captura de datagramas UDP pela interface eth0.
  2. Repita a chamada.
  3. Após encerrar a chamada, analise mensagens SIP no wireshark (menu Telephony -> Voip Calls -> Graph)
  4. Disseque a sinalização SIP entre os softphones.
  5. Identifique como foi transportada a voz digitalizada.


Questões:

  1. Quem foram o UAC e UAS nesse experimento ?
  2. Quantas requisições SIP foram realizadas para uma chamada completa ?
  3. Quantas mensagens, transações, diálogos e chamadas foram realizadas ?
  4. Como a voz digitalizada foi transportada ? Foi usado algum protocolo em especial ?
  5. Qual o CODEC selecionado por cada parte? Onde isso foi feito ?
  6. Qual a lista de CODECS suportados?

04/09: 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 usar o Asterisk na máquina virtual rmu-asterisk. 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]
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](!)
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
context=alunos

[professores](!)
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
context=professores

[coordenacao](!)
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
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
exten=>100,1,Dial(SIP/100)
same=>n,Hangup
exten=>101,1,Dial(SIP/101)
same=>n,Hangup

[professores]; contexto professores
; extensoes dos professores
exten=>200,1,Dial(SIP/200)
same=>n,Hangup
exten=>201,1,Dial(SIP/201)
same=>n,Hangup

[coordenacao]; contexto coordenacao
; extensoes da coordenacao
exten=>300,1,Dial(SIP/300)
same=>n,Hangup
exten=>301,1,Dial(SIP/301)
same=>n,Hangup
include=>alunos
include=>professores
  1. Crie um plano de discagem em que todos podem fazer chamadas para todos. Isso implica haver um único contexto para os canais SIP.
  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.
    • Para executar uma segunda instância do jitsi, use o seguinte comando em um prompt do shell: 
      jitsi -multiple
  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. Identifique as transações (observe os códigos de resposta) e os diálogos.
  8. Crie um novo 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.

Questões:

  1. Que papel desempenhou o Asterisk para os softphones ? UAS, UAC ou algo diferente ?
  2. Entre que agentes ocorreram os diálogos identificados ?
  3. A stream de audio seguiu o mesmo caminho que a sinalização SIP ?
  4. Como o Asterisk conseguiu identificar o telefone chamado (i.e. localizar onde ele estava na rede) ?

Como testar as chamadas

Para testar as chamadas, são necessários dois softphones além do Asterisk.

  1. Em cada softphone crie uma conta SIP, que deve ser identificada por ramal@IP_do_PBX (ex: se o PBX tiver IP 192.168.2.110, as contas de alunos podem ser 100@192.168.2.110 e 101@192.168.2.110).
  2. Após definir as contas, verifique se os softphones indicaram que elas estão disponíveis (online). Você pode fazer essa verificação também no próprio Asterisk. Neste caso execute o seguinte comando para acessar o console do Asterisk: 
    sudo rasterisk -vvv
host*CLI> sip show peers
host*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     
101/101                    192.168.2.10      D          11270    OK (6 ms)
102/102                    192.168.2.10      D          63169    OK (12 ms)
2 sip peers [Monitored: 2 online, 0 offline Unmonitored: 0 online, 0 offline]
  3. Se algum dos softphones não aparecer como OK no console do Asterisk, verifique se o número de ramal e a senha configuradas no softphone são os mesmos declarados em /etc/asterisk/sip.conf. Outro teste que se pode fazer é acessar o console do Asterisk, e depois tentar ativar as contas SIP nos softphones (i.e. colocá-las para indisponível ou offline, e depois reativá-las). O Asterisk irá mostrar algumas linhas informativas sobre os registros dos softphones (lembre que ao ativar uma conta SIP, ela é registrada no Asterisk usando uma mensagem SIP do tipo REGISTER).
  4. Se as contas SIP estão devidamente registradas no Asterisk, mas ainda assim as chamadas não são realizadas, o problema deve estar no plano de discagem. Isso fica evidente se ao tentar fazer uma chamada obtém-se uma mensagem de erro do tipo 404 not found. Neste caso, acesse o console do Asterisk e tente novamente fazer a chamada. Veja se o Asterisk informa na tela o motivo para a chamada não ser realizada. Em seguida, confira se seu plano de discagem (/etc/asterisk/extensions.conf) possui uma extensão que satisfaça a chamada que se deseja realizar. Isso é, se você estiver tentando chamar o ramal SIP 101@192.168.2.110, deve haver uma extensão assim: 
    exten=>101,1,Dial(SIP/101)
same=>n,Hangup

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) na 4a feira, 24/04.


06/09: VoIP e Asterisk (continuação)

Nesta aula será concluída a atividade da aula anterior. Em seguida, será apresentado o protocolo RTP, que é usado para o transporte de media em chamadas VoIP. Por fim, será demonstrado o uso de telefones IP, ATAs e telefones convencionais em uma mesma infraestrutura baseada em Asterisk.

O plano de discagem abaixo possibilita chamadas para os números 100 e 101: 

[alunos]
exten=>100,1,Dial(SIP/100)
same=>n,Hangup
exten=>101,1,Dial(SIP/101)
same=>n,Hangup

... que pode ser generalizado com o uso de uma expressão: 

[alunos]
exten=>_1XX,1,Dial(SIP/${EXTEN})
same=>n,Hangup

O plano de discagem acima possibilita chamar qualquer número entre 100 e 199.

Asterisk e PSTN

Um PBX IP como o Asterisk pode realizar chamadas tanto pela rede telefônica convencional (PSTN) quanto pela rede de dados com VoIP. Para isso, são necessárias interfaces de hardware para os diferentes tipos de canais existentes usados na PSTN. Um exemplo simplificado de uma rede telefônica com telefones IP e convencionais pode ser vista abaixo.

Asterisk-khomp1.png
Cenário com telefones IP e convencionais


A rede acima 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, e assim consegue 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. Porém, como já comentado, 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.

No laboratório de Redes 2 existem módulos com esses tipos de interfaces, os quais foram projetados especialmente para serem usados com PBX IP (Asterisk, FreeSwitch e possivelmente outros). Esses módulos se apresentam como placas externas, o que significa que funcionam como se fossem placas de entrada e saída instaladas dentro do computador onde roda o PBX IP. Por causa dessa característica, seu fabricante (Khomp) denominou-os EBS (External Board Series). O modelo existente no laboratório é o EBS Modular, que combina diferentes interfaces em um mesmo módulo. Com esses módulos será possível implantar a rede telefônica privativa mostrada acima.

11/09: Interligando PBX Asterisk por meio de troncos SIP ou IAX2


A interligação entre PBX Asterisk pode ser feita via rede de dados usando os protocolos SIP ou IAX2. No primeiro caso, o encaminhamento de uma chamada entre dois PBX funciona como uma chamada SIP usual, e isso significa que a sinalização é feita com SIP e a media flui em separado com RTP. No segundo caso, o protocolo IAX2 (Inter-Asterisk eXchange) encapsula tanto a sinalização quanto os fluxos de media, o que simplifica o estabelecimento do tronco.

Modelo-pbx-asterisk.png


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 sip.conf extensions.conf
Norte 
[Sul]
type=user
secret=supersecreta
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

 [troncoSIP]
 ; Ligando para a outra central e, na sequência, o "ramal" de destino
 exten => _4XXX.,1,Dial(SIP/ParaSul/${EXTEN})
 same=>n,Hangup
Sul 
[Norte]
type=user
secret=supersecreta
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

 [troncoSIP]
 ;
 ; Ligando para a outra central e, na sequência, o "ramal" de destino
 exten => _2XXX.,1,Dial(SIP/ParaNorte/${EXTEN})
 same=>n,Hangup

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.

Como fazer esta atividade usando o Netkit

O Netkit pode ser usado para realizar experimentos com Asterisk e chamadas SIP. Ele contém o Asterisk, e também dois softwares para teste de chamadas - pjsua e siprtp. Esses recursos podem ser usados para realizar a atividade de hoje, e a configuração do Netkit para começá-la segue abaixo: 

norte[type]=pbx
sul[type]=pbx
fone1[type]=generic
fone2[type]=generic

norte[eth0]=tronco:ip=192.168.2.101/24
sul[eth0]=tronco:ip=192.168.2.102/24
norte[eth1]=lan1:ip=10.0.0.100/24
sul[eth1]=lan2:ip=10.0.1.100/24
fone1[eth0]=lan1:ip=10.0.0.1/24
fone2[eth0]=lan2:ip=10.0.1.2/24

Copie a configuração acima para um arquivo com extensão .conf (ex: tronco.conf), e carregue-a no Netkit. Execute a rede, e então configure o asterisk, cujos arquivos estão em /etc/asterisk. Para testar as chamadas, use o pjsua ou siprtp (mais simples, mas não é capaz de registrar no Asterisk).

13/09: 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-lab3.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:

  • 7XXX: números do professor
  • 1XXX: números do aluno 1
  • 2XXX: números do aluno 2
  • 3XXX: números do aluno 3
  • 4XXX: números do aluno 4
  • 5XXX: números do aluno 5

... e assim por diante.

18/09: Investigando os protocolos envolvidos nas chamadas

Sinalização com SIP

As chamadas que realizamos por meio do Asterisk foram iniciadas e terminadas usando protocolo SIP. Elas podem ser enquadradas em dois casos:

  1. Chamada com intermediação de gateway de midia
  2. Chamada com intermediação de gateway de midia, porém usando re-INVITE

Os diagramas a seguir servem para melhor entender como ocorrem as comunicações em cada caso.

Chamada entre dois agentes SIP com intermediação de um gateway de media

Este caso é parecido com o anterior, que usa um proxy SIP. A diferença está na intermediação do fluxo de media, que é feita pelo gateway de media. Isso possibilita que dois agentes estabeleçam uma chamada mesmo usando codecs diferentes, pois o gateway de media fará a tradução entre codecs. 

Fone 1            PBX IP              Fone 2
              (directmedia=no)        
     |                |                |
     |   INVITE       |                |
     |--------------->|   INVITE       |
     |  100 Trying    |--------------->| 
     |<---------------|  100 Trying    |
     |                |<---------------| 
     |                |   180 Ringing  |
     |   180 Ringing  |<---------------|                
     |<---------------|                |      
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |     ACK        |                |
     |--------------->|    ACK         |
     |                |--------------->|
     |    RTP Media   |   RTP Media    |
     |<==============>|<==============>|
     |     BYE        |                |
     |--------------->|    BYE         |
     |                |--------------->|
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |                |                |

Chamada entre dois agentes SIP com intermediação de um gateway de media e uso de re-INVITE

O uso de re-invite possibilita que o fluxo de media seja estabelecido diretamente entre os agentes SIP, caso usem o mesmo codec. Assim, evita-se a carga de processamento envolvida na intermediação pelo gateway de media. Isso é feito com o envio pelo gateway de media (representado abaixo por um PBX IP) de um novo INVITE para cada agente SIP, após a sessão SIP estar estabelecida. Esse novo INVITE contém uma descrição de media (mensagem SDP embutida no corpo da mensagem INVITE) com a localização do outro agente SIP - isso é, seu endereço IP, port UDP para a stream RTP e codec a ser usado. 

Fone 1            PBX IP              Fone 2
              (directmedia=yes)        
     |                |                |
     |   INVITE       |                |
     |--------------->|   INVITE       |
     |  100 Trying    |--------------->| 
     |<---------------|  100 Trying    |
     |                |<---------------| 
     |                |  180 Ringing   |
     |  180 Ringing   |<---------------|                
     |<---------------|                |      
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |     ACK        |                |
     |--------------->|    ACK         |
     |    INVITE      |--------------->|
     |<---------------|   INVITE       |
     |    200 OK      |--------------->|
     |--------------->|    200 OK      |
     |    ACK         |<---------------|
     |--------------->|    ACK         |
     |                |<---------------| 
     |                                 |
     |              RTP Media          |
     |<===============================>|
     |     BYE        |                |
     |--------------->|    BYE         |
     |                |--------------->|
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |                |                |

Atividade

  1. Execute o wireshark no hospedeiro, e deixe-o capturando datagramas UDP (especifique isso em Capture->options).
  2. Realize uma chamada entre dois softphones, usando as contas do seu servidor Asterisk.
  3. Observe as mensagens trocadas entre softphones e Asterisk (use menu Telephony->VoIP Calls e depois Graph). Em particular, observe quem é o receptor e transmissor de cada mensagem SIP e também dos pacotes de midia (protocolo RTP).
  4. Edite o arquivo sip.conf do seu Asterisk, e defina a opção directmedia=yes (isso deve estar no perfil que você definiu para as contas). Faça o Asterisk reler o sip.conf: 
    rasterisk
> sip reload
  5. Refaça a chamada entre os softphones, e observe no wireshark as mensagens SIP e pacotes RTP. O que mudou em relação à chamada anterior ?
  6. Em qual caso, dentre os apresentados no início da aula, cada chamada se enquadra ? O que se pode concluir quanto ao papel do Asterisk em cada caso ?

O transporte de midia com protocolo RTP


O protocolo RTP (Real-Time Protocol) foi desenvolvido para possibilitar o transporte de datagramas de tempo-real contendo voz, video, ou outro tipo de dados, sobre IP. Tanto H.323 quanto o modelo SIP usam RTP para o transporte de media, tornando-o o padrão mais comum para comunicações desse tipo na Internet. Apesar desse protocolo não prover qualidade de serviço (i.e. ele não possui mecanismos para atender tais tipos de requisitos), ele torna possível a detecção de alguns dos problemas introduzidos por uma rede IP, tais como:

  • Perda de pacotes
  • Atraso fim-a-fim variável
  • Chegada de pacotes fora de ordem


Esses problemas não são novidade ... nós já os discutimos nas aulas sobre transmissão de dados multimidia. O que há de novo é um protocolo que dá subsídios para as técnicas que buscam atender requisitos de qualidade de serviço. Esses subsídios são informações providas pelo RTP para ajudar a identificar os problemas citados acima, as quais são:

  • Identificação do tipo do conteúdo que está sendo carregado (codec): isso informa ao receptor como ele deve decodificar o conteúdo transportado (ver esta tabela de identificadores de codec usados pelo RTP)
  • Numeração de sequência: essa informação possibilita identificar pacotes perdidos ou fora de ordem.
  • Marcação de tempo (timestamp): com isso é possível efetuar o cálculo de variação de atraso e implementar algum mecanismo de sincronização com a fonte (ex: atraso de reprodução).


Essas informações fazem parte da PDU RTP, como se pode ver a seguir:

Localização do RTP na camada de transporte Cabeçalho RTP
Rtp1.png Rtp-header.png

RTCP

Além do RTP, o protocolo auxiliar RTCP (Real-Time Control Protocol, também definido na RFC 3550) foi definido para o monitoramento da entrega dos pacotes (recepção da stream). Com esse protocolo, os participantes de uma sessão de media podem fazer o intercâmbio de relatórios e estatísticas. Cada tipo de relatório é transportado por um tipo de pacote RTCP. O uso de relatórios possibilita o feedback sobre a qualidade da comunicação, incluindo informações como:

  • Número de pacotes enviados e recebidos
  • Número de pacotes perdidos
  • Jitter (variação de atraso)

Os cinco tipos de relatórios são:

  • Relatório do transmissor (Sender Report - SR)
  • Relatório do receptor (Receiver Report - RR)
  • Descrição da fonte (Source Description - SDES)
  • Bye
  • Específico da aplicação (Application Specific - APP)

Como o tráfego RTCP é puramente overhead, o protocolo foi projetado para que seu consumo da capacidade da rede seja constante, não importa quantos participantes da sessão de media existam. A ideia é que quanto mais participantes houver, menos frequentemente os relatórios RTCP são enviados. Por exemplo, se em uma conferência houver somente dois participantes, os relatórios podem ser enviados a cada 5 segundos. Se houver quatro participantes, os relatórios são enviados a cada 10 segundos. Com isso o consumo de banda para relatórios se mantém constante e previsível.

Atividade

Essa atividade busca ilustrar os fluxos RTP com um exemplo:

  1. Estabeleça uma chamada VoIP entre dois softphones usando o Asterisk como intermediário.
  2. Execute o wireshark no computador onde roda o Asterisk, 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 audio.
  5. Observe os relatórios RTCP:
    • Que tipos de relatórios são enviados ?
    • Com que frequência esses relatórios são transmitidos ?
    • Que informações esses relatórios contêm ?

20/09: retomando a interligação entre PBX Asterisk

Hoje vamos completar a atividade iniciada em 13/09, além de agregar à rede a possibilidade de fazer e receber chamadas da PSTN (tanto fixa quanto celular). Para isso usaremos os módulos EBS da Khomp.

25/09: URA (Unidade de Resposta Audível) e prática com Asterisk: aplicações e funções típicas de PBX

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()

A implantação de uma URA (e de muitas outras funções típicas de PBX) 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 desses recursos, que usaremos para implantar uma URA.

Funções usando o plano de discagem

Para implantar funcionalidades conhecidas ou novas no Asterisk usando o plano de discagem, devem-se conhecer alguns recursos avançados. Aqui são apresentados três deles: extensões especiais, aplicações, padrões de extensões e variáveis.

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.

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

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

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

NoOp

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

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

Padrões de extensões

Extensões podem ser representadas de forma compacta com padrões de extensões. Com esse recurso, muitas extensões podem ser atendidas com um único conjunto de regras, evitando um plano de discagem repetitivo. Por exemplo, se uma empresa possui ramais entre 100 e 199, o plano de discagem pode ser escrito assim: 

exten=>_1XX,1,Dial(SIP/${EXTEN})
same=>n,Hangup

A extensão _1XX contida na primeira linha está escrita como um padrão (pattern), pois inicia com o caractere _. Os caracteres que seguem _ indicam cada dígito que deve aparecer para satisfazer essa extensão. Nesse exemplo, deve aparecer 1 seguido de dois dígitos quaisquer entre 0 e 9 (é esse o significado do caractere X). Desta forma, essa extensão atende qualquer número entre 100 e 199. Por fim, o número de fato chamado é armazenado na variável ${EXTEN}, que pode assim ser usada dentro da regra de discagem.

Alguns caracteres têm significado especial em padrões, como mostrado no exemplo (caractere X). A tabela abaixo lista esses caracteres:

Caractere Descrição
X Qualquer dígito entre 0 e 9
Z Qualquer dígito entre 1 e 9
N Qualquer dígito entre 2 e 9
[13-6] Qualquer dígito entre os colchetes (no exemplo, 1,3,4,5,6)
. Qualquer sequência de um ou mais dígitos
! Qualquer sequência de zero ou mais dígitos

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

Algumas outras 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)

Atividade

  1. Crie a URA Tabajara, conforme o vídeo visto na aula.
  2. Modifique a URA da questão 1 para que a mensagem de menu seja apresentada no máximo duas vezes.

TAREFA: Leitura da semana

Leia o texto abaixo e prepare uma apresentação para próxima 4a feira - 02/10:

27/09 e 28/09: infraestrutura VoIP; integração com DNS

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.


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.

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 ...

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 5 5060 nome.do.servidor.sip.

... sendo 0 a prioridade desse servidor (positivo, e quanto menor, maior a prioridade), 5 o peso do servidor (para servidores com mesma 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 implantar provedores VoIP que encaminharão chamadas de acordo com os domínios especificados nas URI SIP. Assim, cada conta SIP se vincula a um provedor de acordo com seu domínio. Os domínios são da forma provedorX.rmu.sj.ifsc.edu.br, sendo X um número. Serão usadas as máquinas virtuais existentes na DMZ do câmpus - as mesmas dos seus servidores de video.

Leitura complementar

A integração entre PSTN e VoIP tem o potencial de estender o serviço de telefonia, com a liberdade que o modelo da Internet confere à criaçção de novos serviços e aplicações. Uma peça-chave para que essa integração ocorra é o mapeamento entre usuários VoIP e números de telefone da PSTN. O serviço ENUM foi proposto buscando atender essa necessidade, e fazendo uso do DNS. Leiam os textos abaixo para se informarem mais sobre essa proposta:

02/10: Revisão

A avaliação 1 será dia 09/10 e cobrirá os assuntos estudados até dia 02/10.

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:

Trabalho 2

O 2o trabalho de RMU trata de implantar um serviço VoIP englobando várias redes. O cenário considerado contém um PBX de um provedor, que intermedia chamadas vindas de clientes. A rede do trabalho está mostrada abaixo:

Rmu-Trab-2013-2.png
A rede com os PBX e telefones IP


Os clientes do provedor possuem seus próprios PBX IP, que interagem com os PBX dos provedores por meio de troncos SIP ou IAX2. O PBX cliente A possui também uma URA, que possibilita encaminhar chamadas para setores de suporte ou vendas (as chamadas devem ser gravadas). Esses serviços devem ser implantados usando-se o Netkit, e para isso o arquivo de configuração da rede segue abaixo:

  • trab2-2013-2.netkit: Arquivo de configuração do Netkit
    • Importe-o por meio do menu File->Import from file.
    • Sempre ao final de de um experimento execute File->Export após terminar a rede. Isso fará um backup do seu projeto, incluindo a configuração do Asterisk nos PBX e o arquivo /root/pjsua.cfg em cada uma das máquinas virtuais fone.

O Provedor 1 tem código de área 48, e o provedor 2 tem código de área 49. Para fazer uma chamada para um número de outro provedor deve-se prefixá-lo com 0+código de área.

As numerações dos clientes são da seguinte forma:

  • 4 dígitos definidos pelo provedor para representar o cliente, seguidos de 4 dígitos que são definidos pelo cliente.

Como testar chamadas no Netkit

O Netkit possui duas ferramentas que simulam chamadas:

  • siprtp: esse programa possibilita fazer chamadas com áudio sintetizado, no entanto possui algumas restrições para ser usado com o Asterisk (maiores detalhes).
  • pjsua: esse programa é mais completo, sendo capaz de realizar chamadas muito próximas do real. Ele é até capaz de gerar o audio a partir de arquivos de som. Ao contrário do siprtp, o pjsua é capaz de se registrar no Asterisk.

Note também que a configuração da rede conecta os switches das LANs dos clientes à rede real (ver switch brige). Com isso é possível efetuar testes com telefones IP ou softphones, realizando de fato chamadas VoIP.

Usando o pjsua

O pjsua possui muitas funcionalidades que o tornam um agente SIP quase completo (faltaria ao menos suportar re-invite). Para usá-lo existem muitas opções de linha de comando, conforme descrito em seu manual. Aqui se demonstra como fazer uma chamada com dois pjsua registrados em um PBX Asterisk.

  1. Inicie o Asterisk nos PBX, executando este comando em cada um deles: 
    asterisk
rasterisk -vvv
    Obs: "rasterisk -vvv" serve somente para que você possa monitorar o funcionamento do Asterisk
  2. Em cada máquina virtual fone existe um arquivo /root/pjsua.cfg, que contém configurações usuais para rodar o pjsua. Desta forma, evita-se ter que digitá-las sempre que se iniciar o programa. Deve-se executar o pjsua da seguinte forma para que use esse arquivo de configuração: 
    pjsua --config-file=/root/pjsua.cfg
  3. O arquivo de configuração tenta registrar automaticamente o pjsua no Asterisk. As contas SIP pre-configuradas para fins de demonstração são:
  4. Ao rodar o pjsua, confira no PBX correspondente se ele foi devidamente registrado. Assim, execute o seguinte no prompt do rasterisk desse PBX: 
    sip show peers
    O resultado deve ser parecido com este (no meu caso, eu ativei dois pjsua), em que se nota o Status OK para as contas SIP:

    Rasterisk1.png

  5. A tela do pjsua mostra um menu com os comandos que podem ser usados, como mostrado na seguinte figura:

    Pjsua1.png

  6. Para fazer uma chamada, use o comando m. Ao digitá-lo e teclar ENTER, será pedida a URL do contato a ser chamado:

    Pjsua2.png

  7. Uma vez tendo a chamada estabelecida, pode-se usar o comando dq para monitorar a qualidade da comunicação:

    Pjsua3.png

  8. Para encerrar a chamada, use o comando ha.

Ajustes na configuração do pjsua

O arquivo de configuração pjsua.cfg que foi fornecido contém configuração de demonstração. Ao fazer as suas modificações nas configurações dos PBX para realizar o trabalho, será necessário também ajustar esse arquivo. Abaixo segue o conteúdo do pjsua.cfg que está em fone1: 

#
# User agent:
#
--auto-answer 200
--max-calls 4
--registrar sip:192.168.1.100
--proxy sip:192.168.1.100;lr
--realm *
# Abaixo devem ser especificados os dados da conta SIP
--id sip:100@ifsc.edu.br
--username 100
--password 100

#
# Logging options:
#
--log-level 3
--app-log-level 4

#
# Network settings:
#
--local-port 5060

#
# Media settings:
#
--null-audio
--snd-auto-close 1
--rtp-port 4000

#
# SIP extensions:
#
--use-timer 1

# Desativa deteccao de silencio
--no-vad

O que pode ser necessário modificar são os dados da conta SIP a ser usada pelo pjsua. Isso é especificado nas linhas 10, 11 e 12.

Entrega do trabalho

O trabalho deve ser entregue até dia 16/10. Ele pode ser realizado por equipes de até duas pessoas. A entrega deve ser composta de:

  • Um relatório explicando como foi implantado todo o serviço VoIP, explicando as regras de discagem e o cadastro dos telefones IP.
  • Um arquivo de projeto do Netkit contendo as configurações realizadas. Esse arquivo deve ser gerado pelo menu File->Export, após encerrar a execução da rede no Netkit.

Obs: eu posso fazer questionamentos aos membros das equipes para esclarecer o que foi feito no trabalho.

04/10: 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.20.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 172.18.20.251 com o ramal 20001 a 2010 (com senha=número_do_ramal).
  2. Faça este download:
    wget http://172.18.20.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 ?

09/10: Avaliação 1

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

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:

11/10: Conceitos básicos sobre QoS

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.

OBS: para o problema de enfileiramentos RR e WFQ:

  • classe 1 (peso 2 no caso do WFQ) = pacotes 2,3,6,8,9,12
  • classe 2 (peso 4 no caso do WFQ) = pacotes 4,5,7,10,11

No caso do enfileiramento com prioridades: pacotes ímpares são mais prioritários.


18/10: 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

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) Antes de mais nada, deve-se limitar a banda do enlace ponto-a-ponto (entre r1 e r2) a 256 kbps. Crie o arquivo /root/qdisc.sh em cada um desses roteadores, e grave neles o seguinte: 

#!/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

Obs: isso implanta uma qdisc do tipo HTB (ser vista com detalhes numa aula posterior) para fazer a limitação de banda. Após criar o arquivo /root/qdisc.sh, execute-o: 

bash /root/qdisc.sh

2) 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.

3) 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.

4) 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 eth1. 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 /root/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
    ... e em seguida execute-o: 
    bash /root/qdisc.sh
  • Repita o ítem 2, e observe as perdas de pacotes e jitter da chamada VoIP. Houve melhora ?

5) 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

6) E se for desejável limitar o atendimento com qualidade de até quatro chamadas, deixando o restante da capacidade do link para transferências de dados ? Pense numa forma de fazer isso usando as disciplinas de filas do Linux (dica: veja a qdisc TBF).

  • Implemente essa limitação nos roteadores.
  • Teste qual a taxa disponível para transferências de dados.
  • verifique se até quatro chamadas simultâneas podem ser atendidas a contento.


30/10: 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 > /dev/null 2>&1

# 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.

Exemplo de como criar um classificador baseado em endereços IP: 

# classifica de acordo com o endereço IP de destino do datagrama
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 4.3.2.1/32 flowid 1:22


# classifica de acordo com o endereço IP de origem do datagrama
tc filter add dev eth1 protocol ip parent 1:0 prio 2 u32 match ip src 4.3.2.1/32 flowid 1:22

# classifica de acordo com o endereço IP de origem do datagrama E se for UDP
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32 
match ip protocol 17 0xff flowid 1:22

# classifica de acordo com o endereço IP de origem do datagrama E port de origem 80
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32 
match ip sport 80 0xffff flowid 1:22

# classifica de acordo com o endereço IP de origem do datagrama E port de destino 80
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32 
match ip dport 80 0xffff flowid 1:22
Regras para o r2 
#!/bin/bash
 
IFACE=eth1
 
tc qdisc del dev $IFACE root > /dev/null 2>&1
 
# adiciona a qdisc raiz na interface eth0
tc qdisc add dev $IFACE 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 $IFACE parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit
 
# cria as classes das aplicações

# Regras para pc1
tc class add dev $IFACE parent 1:1 classid 1:21 htb rate 256kbit ceil 512kbit
tc class add dev $IFACE parent 1:21 classid 1:31 htb prio 1 rate 90kbit ceil 90kbit
tc class add dev $IFACE parent 1:21 classid 1:32 htb prio 2 rate 166kbit ceil 512kbit

# Regras para pc2
tc class add dev $IFACE parent 1:1 classid 1:22 htb rate 256kbit ceil 512kbit
tc class add dev $IFACE parent 1:21 classid 1:33 htb prio 1 rate 180kbit ceil 180kbit
tc class add dev $IFACE parent 1:21 classid 1:34 htb prio 2 rate 76kbit ceil 512kbit

# Regras para pc3
tc class add dev $IFACE parent 1:1 classid 1:23 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 match ip src 192.168.2.1/32 flowid 1:31

tc filter add dev $IFACE protocol ip parent 1:0 prio 2 u32 match ip src 192.168.2.1/32 flowid 1:32

tc filter add dev $IFACE protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff match ip src 192.168.2.2/32 flowid 1:33

tc filter add dev $IFACE protocol ip parent 1:0 prio 2 u32 match ip src 192.168.2.2/32 flowid 1:34


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 ?
  • DESAFIO: faça um programa ou script que implante uma disciplina WFQ no Linux.


Exercícios

Sobre disciplinas de filas e QoS.

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

01/11: continuação dos exercícios

Uma forma alternativa de classificar pacotes para as qdisc:

  • Usando o iptables: na tabela mangle usa-se o alvo CLASSIFY para associar um datagrama a uma classe. 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

# datagramas da classe DSCP AF41 vão para a classe 1:21 do tc
iptables -t mangle -A FORWARD -p tcp --sport 80 -j CLASSIFY --set-class 1:12
iptables -t mangle -A FORWARD -p tcp --sport 443 -j CLASSIFY --set-class 1:12

Dicas para o iptables

Uma regra com iptables deve especificar basicamente quatro coisas:

  • Tabela: a tabela indica a finalidade da regra. No caso do classificador, deve ser mangle. Essa tabela contém regras que modificam valores de cabeçalhos de pacotes (no caso, a classe/qdisc).
  • Chain: em que chain deve ser adicionada.
    • No caso do classificador, deve-se usar a chain FORWARD (avalia as regras logo após consultar a tabela de rotas).
  • 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.
    • Dependendo do alvo pode haver opções adicionais .


Por exemplo, a regra abaixo marca com o DSCP AF41 os datagramas vindos da rede 172.18.0.0/16:


Iptables-diffserv.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

06/11: 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 101110 (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

Dicas para o iptables

Uma regra com iptables deve especificar basicamente quatro coisas:

  • Tabela: a tabela indica a finalidade da regra. No caso do classificador/marcador e também do PHB, deve ser mangle. Essa tabela contém regras que modificam valoers de cabeçalhos de pacotes (no caso, o DSCP).
  • Chain: em que chain deve ser adicionada.
    • No caso do classificador/marcador, deve-se usar a chain PREROUTING (avalia os pacotes antes de serem roteados).
    • No caso do PHB, deve-se usar a chain FORWARD (avalia as regras logo após consultar a tabela de rotas).
  • 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.
    • Dependendo do alvo pode haver opções adicionais .


Por exemplo, a regra abaixo marca com o DSCP AF41 os datagramas vindos da rede 172.18.0.0/16:


Iptables-diffserv.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

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

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 1256 kbps, e Tabajara contratou um link de 512 kbps. 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).

PARA TESTAR:

  • Verifique se os pacotes estãop devidamente marcados (isso pode ser feito em N1 usando tcpdump ou wireshark)
  • Teste se a vazão esperada para dados está sendo obtida. Use o netperf: 
    netperf -f k -H IP_do_outro_computador
  • Teste também chamadas VoIP usando o siprtp.


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 PCMU, 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 GSM, e a stream de video use 256 kbps, use a estrutura DiffServ para atender essa demanda.


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).

08/11: DiffServ em roteador Linux (continuação)

  • Continuou-se a a atividade proposta na aula de 06/11.
  • Testou-se o software VisualTC, desenvolvido no TCC do Luiz Gustavo Ender.
    • Deve-se executar o VisualTC na máquina real.
    • Deve-se criar a hierarquia de qdisc, e copiar o shell script resultante para dentro do Netkit.
    • No Netkit deve-se testar o funcionamento das qdisc geradas.
    • Deve-se responder o questionário de avaliação do VisualTC.

13/11: Diffserv (conclusão)

Foi concluída a atividade proposta na aula de 06/11.

TAREFA: Pesquisa sobre mecanismos de QoS em roteadores reais

Para próxima 4a feira (20/11):


Façam uma pesquisa sobre as disciplinas de fila, mecanismos de condicionamento de tráfego e suporte a Diffserv existentes em roteadores e switches de UM dos seguintes fabricantes:

Fabricante Aluno
Cisco Nicole
Enterasys Maicky
Alcatel Francisco
Juniper Leandro
HP/3Com Liamari
Huawei Maycon
IBM
Avaya
D-Link Aliny

... e prepare uma curta apresentação mostrando esses mecanismos, o que são capazes de fazer, que parâmetros são tipicamente necessários para usá-los (ex: taxa média, taxa de pico, peso, prioridade, ...), e como são utilizados para implantar Diffserv nesses roteadores.

OBS: Cada aluno deve escolher um fabricante.

20/11: 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.

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

Leia os dois textos abaixo, e preparem uma breve apresentação para dia 27/11 que explique os conceitos básicos de MPLS-Diffserv e MPLS-TE, e compare-os evidenciando suas características e diferenças.

  • Leiam até a seção 3.2 (inclusive) deste texto sobre MPLS e Diffserv
  • Leiam 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.

22/11: 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).

Iptables-fluxo-filter.png


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: 
      #!/bin/bash

# Limpa as regras existentes
iptables -F

# 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: 
      #!/bin/bash

# Limpa as regras existentes
iptables -F

# 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. 
    # 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,RELATED -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
    • Versão alternativa, usando o módulo multiport: 
      # 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
  3. Caso 3: os computadores internos podem acessar qualquer serviço, com exceção de redes eDonkey (ex: emule) e torrent.

23/11: Firewall

Realização dos exercícios da aula de 22/11, 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). Para quem usou o Netkit, a 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.

  • Regras específicas para as chamadas VoIP (Obs: PBX=192.168.2.101, e ports RTP configuradas no Asterisk vão de 36540 a 36999):
iptables -A FORWARD -i $WAN -s 192.168.2.101 --sport 36540:36999 -d 10.1.X.0/24 -j ACCEPT
iptables -A FORWARD -i $LAN -d 192.168.2.101 --dport 36540:36999 -s 10.1.X.0/24 -j ACCEPT
iptables -A FORWARD -i $LAN -d 192.168.2.101 --dport 5060 -s 10.1.X.0/24 -m state --state NEW -j ACCEPT

TAREFA: Leitura da semana

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

27/11: Firewall

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

29/11: 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 discuti-lo na aula de 06/12. Leiam as seções 1 a 4 (se quiserem ler todo o resto, fiquem à vontade ;-).

04/12: 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
Uma possível solução 
# bloqueia tudo por default
iptables -P INPUT DROP
iptables -P FORWARD DROP

# redireciona os ports smtp, dns, ssh, http e https para os servidores
# da DMZ
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2 
iptables -t nat -A PREROUTING -i eth0 -p udp -m udp --dport 53 -j DNAT --to-destination 10.0.0.2 
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 10.0.0.2:22 
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 2200 -j DNAT --to-destination 10.0.0.1:22 
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80 
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.1 

# Faz NAT de tudo que sai em direcao a Internet
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 

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

# Libera novos fluxos vindos da rede interna em direcao a Internet
iptables -A FORWARD -i eth2 -o eth0 -m state --state NEW -j ACCEPT

# Libera ports smtp,ssh,dns,http e https para os servidores da DMZ
iptables -A FORWARD -p tcp --dport 25 -d 10.0.0.2 -m state --state NEW -j ACCEPT 
iptables -A FORWARD -p tcp --dport 22 -d 10.0.0.2 -m state --state NEW -j ACCEPT 
iptables -A FORWARD -p udp --dport 53 -d 10.0.0.2 -m state --state NEW -j ACCEPT 
iptables -A FORWARD -p tcp --dport 22 -d 10.0.0.1 -m state --state NEW -j ACCEPT 
iptables -A FORWARD -p tcp --dport 80 -d 10.0.0.1 -m state --state NEW -j ACCEPT 
iptables -A FORWARD -p tcp --dport 443 -d 10.0.0.1 -m state --state NEW -j ACCEPT 

# registra todos os pacotes bloqueados
iptables -A FORWARD -j LOG
iptables -A INPUT -j LOG

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.
  • 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).
Uma possível solução 
# bloqueia tudo por default
iptables -P INPUT DROP
iptables -P FORWARD DROP

# redireciona os ports smtp, dns, ssh, http e https para os servidores
# da DMZ
iptables -t nat -A PREROUTING -i eth2 -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2 
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2 
iptables -t nat -A PREROUTING -i eth0 -p udp -m udp --dport 53 -j DNAT --to-destination 10.0.0.2 
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 10.0.0.2:22 
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 2200 -j DNAT --to-destination 10.0.0.1:22 
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80 
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.1 

# Faz NAT de tudo que sai em direcao a Internet
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 

# libera fluxos já estabelecidos para o firewall
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 

# libera acesso vindo da rede interna ao proxy http no firewall.
iptables -A INPUT -i eth2 -p tcp --dport 3128 -m state --state NEW -j ACCEPT 

# libera acesso vindo de qualquer lugar a ssh no firewall.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT 

# libera novos fluxos e fluxos já estabelecidos vindos do firewall
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
iptables -A OUTPUT -m state --state NEW -j ACCEPT 

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

# Bloqueia conexoes para web e smtp na Internet vindos da rede interna
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 80 -j DROP
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 8080 -j DROP
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 443 -j DROP
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 3128 -j DROP
iptables --A FORWARD -i eth2 -o eth0 -p tcp --dport 25 -j DROP

# Libera novos fluxos vindos da rede interna em direcao a Internet
iptables -A FORWARD -i eth2 -o eth0 -m state --state NEW -j ACCEPT

# Libera conexoes smtp e consultas DNS vindas da DMZ
iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 25 -s 10.0.0.2 -m state --state NEW -j ACCEPT 
iptables -A FORWARD -i eth1 -o eth0 -p udp --dport 53 -s 10.0.0.2 -m state --state NEW -j ACCEPT 

# Libera ports smtp,ssh,dns,http e https para os servidores da DMZ
iptables -A FORWARD -p tcp --dport 25 -d 10.0.0.2 -m state --state NEW -j ACCEPT 
iptables -A FORWARD -p tcp --dport 22 -d 10.0.0.2 -m state --state NEW -j ACCEPT 
iptables -A FORWARD -p udp --dport 53 -d 10.0.0.2 -m state --state NEW -j ACCEPT 
iptables -A FORWARD -p tcp --dport 22 -d 10.0.0.1 -m state --state NEW -j ACCEPT 
iptables -A FORWARD -p tcp --dport 80 -d 10.0.0.1 -m state --state NEW -j ACCEPT 
iptables -A FORWARD -p tcp --dport 443 -d 10.0.0.1 -m state --state NEW -j ACCEPT 

# registra todos os pacotes bloqueados
iptables -A FORWARD -j LOG
iptables -A INPUT -j LOG
Outra possível solução, e que explora a hierarquização de chains 
# bloqueia tudo por default
iptables -P INPUT DROP
iptables -P FORWARD DROP

# Cria uma nova chain na tabela nat, para conter as regras que
# se aplicam a pacotes vindos da Internet.
iptables -t nat -N vindo_de_fora

# redireciona os ports smtp, dns, ssh, http e https para os servidores
# da DMZ
iptables -t nat -A PREROUTING -i eth2 -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2 
iptables -t nat -A PREROUTING -i eth0 -j vindo_de_fora
iptables -t nat -A vindo_de_fora -p udp -m udp --dport 53 -j DNAT --to-destination 10.0.0.2 
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.0.0.2 
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 2201 -j DNAT --to-destination 10.0.0.2:22 
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 2200 -j DNAT --to-destination 10.0.0.1:22 
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80 
iptables -t nat -A vindo_de_fora -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.1 

# Faz NAT de tudo que sai em direcao a Internet
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 

# libera fluxos já estabelecidos para o firewall
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 

# libera acesso vindo da rede interna ao proxy http no firewall.
iptables -A INPUT -i eth2 -p tcp --dport 3128 -m state --state NEW -j ACCEPT 

# libera acesso vindo de qualquer lugar a ssh no firewall.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT 

# libera novos fluxos e fluxos já estabelecidos vindos do firewall
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
iptables -A OUTPUT -m state --state NEW -j ACCEPT 

iptables -N vindo_da_rede_interna
iptables -N vindo_da_dmz
iptables -N indo_para_dmz

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

# desvia o processamento das regras para outras chains,
# dependendo de onde vem ou para onde vai cada pacote.
# Isto serve para evitar ter que verificar muitas regras ...
iptables -A FORWARD -i eth2 -j vindo_da_rede_interna
iptables -A FORWARD -i eth1 -j vindo_da_dmz
iptables -A FORWARD -o eth1 -j indo_para_dmz

# registra todos os pacotes bloqueados
iptables -A FORWARD -j LOG
iptables -A INPUT -j LOG

# Bloqueia conexoes para web e smtp na Internet vindos da rede interna
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 80 -j DROP
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 8080 -j DROP
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 443 -j DROP
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 3128 -j DROP
iptables -A vindo_da_rede_interna -o eth0 -p tcp --dport 25 -j DROP

# Libera novos fluxos vindos da rede interna em direcao a Internet
iptables -A vindo_da_rede_interna -o eth0 -m state --state NEW -j ACCEPT

# Libera conexoes smtp e consultas DNS vindas da DMZ
iptables -A vindo_da_dmz -o eth0 -p tcp --dport 25 -s 10.0.0.2 -m state --state NEW -j ACCEPT 
iptables -A vindo_da_dmz -o eth0 -p udp --dport 53 -s 10.0.0.2 -m state --state NEW -j ACCEPT 

# Libera ports smtp,ssh,dns,http e https para os servidores da DMZ
iptables -A indo_para_dmz -p tcp --dport 25 -d 10.0.0.2 -m state --state NEW -j ACCEPT 
iptables -A indo_para_dmz -p tcp --dport 22 -d 10.0.0.2 -m state --state NEW -j ACCEPT 
iptables -A indo_para_dmz -p udp --dport 53 -d 10.0.0.2 -m state --state NEW -j ACCEPT 
iptables -A indo_para_dmz -p tcp --dport 22 -d 10.0.0.1 -m state --state NEW -j ACCEPT 
iptables -A indo_para_dmz -p tcp --dport 80 -d 10.0.0.1 -m state --state NEW -j ACCEPT 
iptables -A indo_para_dmz -p tcp --dport 443 -d 10.0.0.1 -m state --state NEW -j ACCEPT

E como são outros filtros de pacotes ?

Existem outros filtros de pacotes, os quais são usados em outros sistemas operacionais. A lógica de suas regras é muito parecida com a usada no iptables. Portanto, se você entendeu bem como funciona o iptables, pode também aprender rapidamente a usá-los. Veja os exemplos abaixo:

  • Regras com iptables: 
    iptables -P FORWARD DROP

# Libera fluxos estabelecidos
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Libera acessos vindos da rede interna ao servidor DNS externo
iptables -A FORWARD -i eth0 -p udp -d 200.135.37.65 --dport 53 -m state --state NEW -j ACCEPT


# Libera acessos vindos da rede interna para Web
iptables -A FORWARD -i eth0 -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --dport 443 -m state --state NEW -j ACCEPT
  • IP Filter (usado no FreeBSD e Solaris):
    # Obs: dc0 é a interface de rede interna (nomenclatura do FreeBSD)
# Obs 2: no IP Filter, o próprio filtro bloqueia tudo por default ...

# Libera acessos vindos da rede interna ao servidor DNS externo
pass in quick on dc0 proto udp from any to 200.135.37.65 port = 53 keep state

# Libera acessos vindos da rede interna para Web
pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state 
pass in quick on dc0 proto tcp from any to any port = 443 flags S keep state
  • IPFW (usado no FreeBSD):
    # Libera fluxos estabelecidos
ipfw -q add 10 check-state 

# Libera acessos vindos da rede interna ao servidor DNS externo
ipfw -q add 20 allow udp from any to 200.135.37.65 53 out via dc0 keep-state 

# Libera acessos vindos da rede interna a servidores web externos
ipfw -q add 30 allow tcp from any to any 80 in via dc0 setup keep-state 
ipfw -q add 40 allow tcp from any to any 443 in via dc0 setup keep-state
  • PF (usado no OpenBSD e FreeBSD): 
    # Obs: dc1 é a interface externa
# Obs2: este filtro de pacotes é stateful por default

# opções globais
set block-policy return
set loginterface egress
set skip on lo

# bloqueia todo tráfego entrante por default, e libera o sainte
block in log on dc1
pass out quick on dc0

# Preciso liberar o que vem de dentro (quando entra no firewal ... na saída
# será feita nova verificação).
pass in quick on dc0

# Libera ICMP (ping)
pass out quick on dc1 inet proto icmp all icmp-type echoreq

# Libera dns e web vindos da rede interna
pass out quick on dc1 proto udp from any to 200.135.37.65 port 53
pass out quick on dc1 proto tcp from any to any port 80
pass out quick on dc1 proto tcp from any to any port 443



Projeto final

O projeto final de RMU trata de adicionar firewalls e mecanismos de QoS à rede do projeto 2. Essa rede sofreu uma pequena modificação, com os links das redes dos clientes sendo implantados com ADSL (na verdade, links PPPoE com taxas de downstream de 1 Mbps e upstream de 400 kbps). Outra pequena alteração foi o acréscimo dos firewalls dos provedores (fw1 e fw2), e a inclusão de um servidor web na LAN do provedor 1. Por fim, para reduzir o tamanho da rede foi retirado o cliente C (que continha o pbxc e fone5).


Trab3-2013-2.png
A rede com os PBX, telefones IP, e links PPPoE


As modificações a serem feitas nessa rede devem atender o seguinte:

  • Os diferentes tipos de tráfego devem ter seus requisitos de QoS atendidos:
  • As comunicações dos usuários devem ser policiadas:


A turma deve se dividir em equipes de até 03 alunos.

  • Prazo de entrega: 16/12

Detalhamento

O trabalho será feito usando o Netkit (versão 1.97 ou superior).

  • Arquivo de projeto do Netkit para o trabalho
  • 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.
  • Obs 2: na versão 1.97 do Netkit, o Asterisk pode ser iniciado automaticamente no boot. Isso foi explorado na configuração do projeto. Além do Asterisk, são iniciados automaticamente os servidores SSH nos firewalls, e o Apache em web.


Requisitos:

  • As redes dos clientes usam NAT para acessar a rede WAN. A rede do provedor usa IPs públicos.
  • 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.
  • O servidor web do provedor pode ser acessado da Internet para serviço Web (protocolos HTTP e HTTPS nas portas padrões).
  • Firewalls dos clientes (r1 e r2) e dos provedores (fw1 e fw2) podem ser acessados da Internet com SSH.
  • 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 nos Firewalls.
  • A implantação de um domínio Diffserv é opcional ... mas isso possibilitaria ter QoS de forma mais consistente na rede.

NAT e Asterisk

O NAT exige algumas configurações especiais para o Asterisk, do contrário as chamadas não funcionam (principalmente o que diz respeito ao RTP).

13/12: Avaliação 3

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

18/12: Recuperação

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