quarta-feira, 2 de novembro de 2016

Controlador de Domínio do SAMBA 4 no Debian GNU/Linux

Olá Pessoal,

Em outro artigo intitulado "Configuração Básica do SAMBA em Servidores Linux" o leitor passou pela experiência básica de como fazer o simples compartilhamento de diretórios e arquivos através do SAMBA para integrar ambientes heterogêneos com máquinas Linux e Windows. No entanto, é importante destacar que o SAMBA 4 vai muito além do simples compartilhamento e permite que o servidor Linux assuma o papel de controlador de domínio (DC). Assim é possível ingressar máquinas Windows no serviço de diretório do servidor Linux para que a gerência dos objetos de um domínio (computadores, contas de usuários, políticas, etc) seja centralizada sem a necessidade do MS Windows Server, o que implica em economia na licença do sistema operacional do servidor e também da quantidade de clientes da rede (CAL).




O objetivo deste artigo é listar as etapas necessárias para instalar o SAMBA 4 (e seus complementos) para transformar um servidor Debian GNU/Linux no controlador do domínio denominado AULA.LOCAL. Nesse exemplo assumiremos que nosso controlador de domínio será configurado com o IP 192.168.221.1/24. Uma etapa preliminar é definir estaticamente no arquivo /etc/hosts o mapeamento do nome do servidor que posteriormente será configurado como controlador de domínio. Nessa etapa criaremos um mapeamento estático (NOME<>IP) em que o nome da máquina já será composto com o sufixo do domínio (FQDN) que será utilizado posteriormente. Por causa desse mapeamento o SAMBA irá sugerir o nome de domínio AULA.LOCAL durante sua instalação. 

###--- em /etc/hosts -------------------------
127.0.0.1       localhost
192.168.221.1   samba-dc   samba-dc.aula.local
###--- fim do arquivo ------------------------

1) Instalação do Servidor SAMBA DC

Assim como nos artigos anteriores, estou considerando que o servidor está instalado com a distribuição Debian GNU/Linux (ou seus derivados, como o Ubuntu). A primeira etapa consiste na instalação do pacote denominado samba para que o Linux possa ser posteriormente configurado como controlador de domínio. Também é necessário instalar vários pacotes com outros serviços, a exemplo do DNS (winbind), do Kerberos (krb5-user), etc. Apesar de ser bastante coisa, essa tarefa é simples e rápida através do APT:

root@samba-dc:/# apt-get update
root@samba-dc:/# apt-get install samba smbclient ntp krb5-user winbind ldap-utils acl attr

Durante a instalação irá aparecer um diálogo (modo texto) solicitando 3 informações:

- Nome do Domínio                               : AULA.LOCAL
- Endereço do Servidor Kerberos de Autenticação : 127.0.0.1
- Endereço do Servidor Administrativo           : 127.0.0.1

2) Configuração do NTP p/ Sincronização do Relógio das Máquinas

A próxima etapa é fazer alguns ajustes no serviço NTP responsável pela sincronização do relógio da máquina que será responsável por sincronizar os relógios de todas as demais máquinas do domínio. Depois de criado o diretório ntp_signd com as devidas permissões, é necessário adicionar algumas linhas ao final do arquivo de configuração localizado em /etc/ntp.conf.

root@samba-dc:/# install -d /var/lib/samba/ntp_signd/
root@samba-dc:/# chown root:ntp /var/lib/samba/ntp_signd
root@samba-dc:/# chmod 750 /var/lib/samba/ntp_signd/

###--- em /etc/ntp.conf ------------------------
(...) Conteúdo Omitido
### Adicionar Configuracoes Abaixo p/ SAMBA 4 DC
ntpsigndsocket /var/lib/samba/ntp_signd/
restrict default mssntp
disable monitor
###--- fim do arquivo --------------------------

Depois desses ajustes, basta reiniciar o serviço NTP:

root@samba-dc:/# service ntp restart

O status do serviço NTP pode ser verificado através dos seguintes comandos:

root@samba-dc:/# service ntp status
root@samba-dc:/# ntpq -p

3) Parada de Serviços em Execução

Antes de fazer a configuração do domínio propriamente dito através do processo de provisionamento do SAMBA, é necessário parar serviços que são automaticamente executados logo depois da instalação dos pacotes, além de "remover" o arquivo original de configuração do SAMBA (/etc/samba/smb.conf):

root@samba-dc:/# service smbd stop
root@samba-dc:/# service nmbd stop
root@samba-dc:/# service winbind stop
root@samba-dc:/# mv /etc/samba/smb.conf /etc/samba/smb.conf.bak

4) Provisionamento do Domínio

Uma das etapas mais importantes é o provisionamento do domínio em que serão utilizadas ferramentas automatizadas do próprio SAMBA para preparar nosso servidor como controlador do domínio AULA.LOCAL. A principal ferramenta é o comando samba-tool que serve como frontend responsável por manipular o OpenLDAP (backend), simplificando muito a tarefa de configuração. 

root@samba-dc:/# samba-tool domain provision --use-rfc2307 --interactive

Ao digitar o comandoo sistema irá indagá-lo e sugerir as seguintes configurações que podem ser aceitas através da tecla <ENTER>:

- Realm                       [AULA.LOCAL] 
- Domain                      [AULA]
- Server Role                 [DC]
- DNS Backend                 [SAMBA_INTERNAL]
- DNS Forwarder IP Address    (IP do DNS da REDE)
- Administrator Password      (SENHA FORTE)

Obs.: Os parâmetros trazidos nas chaves [] são sugeridos pelo samba-tool e podem ser aceitos. O servidor DNS integrado ao controlador de domínio será responsável pelos mapeamentos dos nomes na rede interna, de forma que todas as máquinas Windows a serem ingressadas no domínio devem ser configuradas para apontar seu DNS primário para o IP do servidor SAMBA (192.168.221.1). Caso exista(m) outro(s) servidor(es) DNS na rede (por ex. BIND), responsável por exemplo pelo mapeamento de nomes externos, pode ser feito o apontamento através do DNS Forwarder.

5) Ajustes Finais

É hora de fixar as configurações de DNS do servidor no arquivo /etc/resolv.conf e aplicar a característica de imutabilidade (+i) no mesmo para que seu conteúdo não seja mais dinamicamente atualizado. Também vamos copiar o template do arquivo de configuração do Kerberos que vem com o pacote samba (/var/lib/samba/private/krb5-conf) para o diretório /etc para que a autenticação no domínio possa funcionar. Por fim, vamos reiniciar o serviço do SAMBA como controlador de domínio.

###--- em /etc/resolv.conf ---
search aula.local
nameserver 192.168.221.1
###--- fim do arquivo --------

root@samba-dc:/# chattr +i /etc/resolv.conf
root@samba-dc:/# cp /var/lib/samba/private/krb5.conf /etc
root@samba-dc:/# service samba-ad-dc restart

6) Verificação

A primeira maneira de verificar se o SAMBA está em execução é:

root@samba-dc:/# service samba-ad-dc status
Active: active (running) since (...) 

Para fazer uma verificação mais apurada, vale testar a resolução de nomes internos de alguns registros automaticamente criados pelo controlador de domínio, além de testar a resolução de nomes externos:

root@samba-dc:/# host -t A aula.local
aula.local has address 192.168.221.1

root@samba-dc:/# host -t SRV _kerberos._udp.aula.local
_kerberos._udp.aula.local has SRV record 0 100 88 samba-dc.aula.local

root@samba-dc:/# host -t SRV _ldap._tcp.aula.local
_kerberos._tcp.aula.local has SRV record 0 100 88 samba-dc.aula.local

root@samba-dc:/# host www.debian.org
www.debian.org has address 200.17.202.197
www.debian.org has IPv6 address 2801:82:80ff:8009:e61f:13ff:fe63:8388

Finalmente vamos testar a autenticação do Kerberos:

root@samba-dc:/# kinit administrator@AULA.LOCAL
Password for administrator@AULA.LOCAL: <Senha do Administrador do Domínio>
Warning: Your password will expire in 41 days on (...)

root@samba-dc:/# klist
(...) Informações de Validade do Ticket (Kerberos)


7) Administração do Domínio

Pronto, o servidor SAMBA já está em operação como controlador do domínio AULA.LOCAL. A partir deste ponto o domínio pode ser administrador via interface de linha de comando (CLI) através da ferramenta samba-tool. São várias as opções para administração do domínio via samba-tool, por isso é recomendada a leitura do manual da ferramenta (man samba-tool). Abaixo trago uma breve relação de alguns dos comandos mais comuns:

samba-tool user list                  ### exibe todos os usuários do domínio
samba-tool user add <NOME>            ### adiciona um novo usuário
samba-tool user del <NOME>            ### remove um usuário existente
samba-tool user enable <NOME>         ### habilita um usuário desabilitado
samba-tool user disable <NOME>        ### desabilita uma conta de usuário

Caso algum usuário esqueça sua senha, o coomando abaixo pode ser utilizado para resetá-la de forma que o usuário seja obrigado a alterá-la no próximo login:

samba-tool user NOME --newpassword=SENHA --must-change-at-next-login  

Outra opção bastante atrativa é utilizar a ferramenta RSAT (Remote Server Administration Tools) que pode ser baixada gratuitamente na página da Microsoft e instalada em qualquer máquina executando o Windows (versões 7, 8 ou 10). A vantagem dessa abordagem é que a administração do domínio é feita pela mesma interface gráfica das tradicionais Ferramentas Administrativas do Windows Server, aproveitando todo o conhecimento do administrador. O RSAT pode ser baixado através dos links abaixo:

- Windows 7: https://www.microsoft.com/pt-br/download/details.aspx?id=7887 
- Windows 8: https://www.microsoft.com/pt-br/download/details.aspx?id=28972
- Windows X: https://www.microsoft.com/pt-BR/download/details.aspx?id=45520

Obs.: Depois de baixado o RSAT deve ser instalado no Windows e manualmente adicionado como recurso extra. Nos links oficiais da Microsoft onde o RSAT pode ser baixado o leitor encontra as instruções para instalação da ferramenta. 

Façam seus testes...

Samuel.

segunda-feira, 10 de outubro de 2016

Espelhamento de Discos em Servidores Debian GNU/Linux

Olá Pessoal,

Uma prática bastante comum em servidores é a combinação de múltiplos discos físicos em arranjos lógicos denominados RAID (Redundant Array of Independent Discs), principalmente para fins de disponibilidade dos dados aramazenados em mais de um disco e também para fins de desempenho, uma vez que dados armazenados em múltiplos discos implicam em maior velocidade de leitura. 

Há diversas modalidades de RAID, sendo a mais simples delas o RAID-1 que faz o espelhamento de discos, ou seja, mantém em um segundo disco físico uma cópia exata do primeiro disco físico. Em caso de falha de um dos discos, o conteúdo continua disponível através do outro disco e o administrador pode providenciar a troca do disco defeituoso para que haja sincronização total do conteúdo no novo disco.

O RAID normalmente é implementado através de hardware, sendo gerenciado por uma controladora de discos que pode ser configurada através da BIOS (ou UEFI) da máquina antes mesmo do início de instalação do sistema operacional. Essa é a opção mais recomendada porque apresenta melhor desempenho, no entanto só está disponível em hardware particularmente desenvolvido para servidores. Como o Linux se trata de um sistema operacional aberto e gratuito, ele acaba sendo a opção natural em ambientes menores que não têm recursos para aquisição de hardware adequado para seus servidores. Nesses casos, frequentemente são utilizados computadores tradicionais que não possuem hardware apropriado com uma controladora que suporte a implementação de RAID na BIOS/UEFI.

Apesar dessa limitação de equipamento, a boa notícia é que também existe a opção de configurar o RAID por software através dos sistemas operacionais modernos, ainda que o desempenho seja pior que a solução profissional implementada por hardware. Especificamente no caso do Debian GNU/Linux, a configuração de RAID pode ser facilmente implementada durante o próprio processo de instalação do servidor, desde que a máquina tenha pelo menos dois discos físicos.

A configuração de RAID-1 na instalação do Debian consiste basicamente em criar partições idênticas nos dois discos físicos e em marcá-las com o rótulo "physical volume for RAID", ao invés de escolher um sistema de arquivos (figura 1). Depois disso é possível acessar a opção "Configure Software RAID" na própria ferramenta de particionamento do Debian e selecionar as duplas partições que serão agrupadas em RAID-1. Ao terminar de criar os agrupamentos, será possível observar o(s) novo(s) disco(s) lógico(s) do RAID na tabela de partições, onde o administrador deverá fazer a indicação do sistema de arquivos e dos pontos de montagem (figura 2).

Figura 1. Indicação de RAID em 2 Discos Físicos (Antes)
Figura 2. Particionamento de Disco Lógico RAID-1 (Depois)

A implementação do RAID-1 na instalação do Debian GNU/Linux é bastante simples, mas como lidar com o sistema operacional em caso de falha de um dos discos? Como fazer a inserção do novo disco no arranjo lógico e sincronizar os dados em ambos os discos? O objetivo desse artigo é listar as ações necessárias para recompor o RAID em caso de falha de um disco. 

Consideremos um servidor que possui dois HDs (/dev/sda e /dev/sdb) arranjados em RAID-1, cada um deles contendo 3 partições com capacidade de armazenamento apenas simbólica conforme apresentado nas figuras acima. Abaixo trago novamente o esquemático das partições:

/dev/sda1 > +/- 0.6 GB (SWAP)
/dev/sda2 > +/- 7.0 GB (/)
/dev/sda3 > +/- 1.0 GB (/home)

/dev/sdb1 > +/- 0.6 GB (SWAP)
/dev/sdb2 > +/- 7.0 GB (/)
/dev/sdb3 > +/- 1.0 GB (/home)

O RAID-1 de ambos os HDs foi configurado durante o processo de instalação do servidor Linux Debian, através da ferramenta de partição do próprio instalador (na opção Configure Software RAID), dando origem aos seguintes arranjos lógicos do tipo multi-disk (/dev/mdX):

/dev/md0 = /dev/sda1 + /dev/sdb1 (SWAP)
/dev/md1 = /dev/sda2 + /dev/sdb2 (/)
/dev/md2 = /dev/sda3 + /dev/sdb3 (/home)

Enquanto os discos estão operando normalmente, o arranjo lógico dos discos físicos em RAID-1 será responsável por realizar o espelhamento de todo o conteúdo armazenado no primeiro disco também no segundo disco, garantindo que sempre exista uma cópia de segurança dos dados. Caso haja pane em qualquer um dos discos, será necessário repor fisicamente o HD defeituoso e inserí-lo manualmente no arranjo lógico do RAID-1 para que todo o conteúdo do disco em operação possa ser sincronizado novamente no novo HD. 

Por exemplo, em caso de pane no segundo HD (/dev/sdb) será necessário:

1) Reparticionar o novo HD (/dev/sdb) com o mesmo esquema do disco em operação (/dev/sda)

root@Linux:/# sfdisk -d /dev/sda | sfdisk /dev/sdb

Feito isso, é sempre prudente verificar se o novo HD possui as mesmas partições do original:

root@Linux:/# fdisk -l /dev/sda
root@Linux:/# fdisk -l /dev/sdb

2) Adicionar as partições do novo HD (/dev/sdX#) ao RAID (/dev/mdX):

root@Linux:/# mdadm --manage /dev/md0 --add /dev/sdb1 
root@Linux:/# mdadm --manage /dev/md1 --add /dev/sdb2
root@Linux:/# mdadm --manage /dev/md2 --add /dev/sdb3

Feito isso, é possível verificar que o RAID será ressincronizado (espelhamento dos discos), de forma que o novo HD seja preenchido com uma cópia exata do conteúdo armazenado no HD original:

root@Linux:/# cat /proc/mdstat

Personalities : [raid1]
md2  :  active raid1 sda3[0] sdb3[1]
        965056 blocks super 1.2 [2/2] [UU]

md1  :  active raid1 sda2[0] sdb2[1]
        6832128 blocks super 1.2 [2/2] [UU]

md0  :  active (auto-read-only) raid 1 sda1[0] sdb1[1]
        584128 blocks super 1.2 [2/2] [UU]

A saída exibe o status de cada arranjo lógico do tipo multi-disk, sendo que o conteúdo dos colchetes destacados em amarelo exibem o status individual de cada um dos discos físicos. Por exemplo, a saída [UU] indica que ambos os HDs estão em operação, enquanto que a saída [U_] indicaria que o segundo disco físico não está em operação. 

Façam seus testes...

Samuel. 

quarta-feira, 28 de setembro de 2016

Configuração de Ether-Channel e Trunk em Roteadores Cisco

Olá Pessoal,

Assim como a configuração de agregação de interfaces físicas é uma prática comum em links tronco (trunk) de switches para fins de disponibilidade e balanceamento de carga, essa mesma configuração é igualmente importante em roteadores que fazem roteamento inter-VLAN. Para exemplificar a configuração de uma agregação de links em roteadores Cisco, utilizarei o cenário apresentado na figura abaixo em que é necessário configurar roteamento inter-VLAN entre duas sub-redes compostas por máquinas de duas VLANs diferentes, de maneira similar ao exemplo que trago no Lab06 (intitulado Configuração de Switches e VLANs) do livro Laboratórios de Tecnologias Cisco.

A diferença é que no laboratório do livro o roteador está conectado ao switch através de uma única interface física, enquanto que nesse exemplo será configurada uma agregação lógica em duas interfaces físicas do roteadores. Essa prática não só é recomendada para fins de disponibilidade em caso de falha de um dos links, mas também para obter melhor desempenho porque múltiplas VLANs estão atreladas a um único trunk entre o switch e o roteador naquilo que chamamos de router on a stick


Nas linhas abaixo trago as configurações necessárias no roteador para que o roteamento inter-VLAN funcione no cenário proposto, com destaques em amarelo para aqueles comandos que remetem à configuração da agregação propriamente dita. 

Router# configure terminal
Router(config)# interface port-channel 1
Router(config-if)# exit
Router(config)# interface range g0/0 - 1
Router(config-if-range)# channel-group 1
Router(config-if-range)# no shut
Router(config-if(range)# exit
Router(config)# interface po1.10
Router(config-subif)# encapsulation dot1q 10
Router(config-subif)# ip address 192.168.10.254 255.255.255.0
Router(config-subif)# exit
Router(config)# interface po1.20
Router(config-subif)# encapsulation dot1q 20
Router(config-subif)# ip address 192.168.20.254 255.255.255.0
Router(config-sub-if)# exit 
Router(config)# 

Para completar esse laboratório, abaixo trago as configurações do switch:

Switch# configure terminal
Switch(config)# vlan 10
Switch(config-vlan)# name VERDE
Switch(config-vlan)# exit
Switch(config)# vlan 20
Switch(config-vlan)# name VERMELHO
Switch(config-vlan)# exit
Switch(config)# interface range f0/1 - 3
Switch(config-if-range)# switchport access vlan 10
Switch(config-if-range)# exit
Switch(config)# interface range f0/4 - 6
Switch(config-if-range)# switchport access vlan 20
Switch(config-if-range)# exit
Switch(config)# interface range g0/1 - 2
Switch(config-if-range)# switchport mode trunk
Switch(config-if-range)# channel-group 1 mode on
Switch(config-if-range)# exit
Switch(config)# 

Façam seus testes...

Samuel. 

terça-feira, 27 de setembro de 2016

Instalação do Banco de Dados Firebird em Servidores Linux

Olá Pessoal,

O objetivo deste artigo é listar a simples instalação e configuração do Firebird em Servidores Linux. O Firebird é um popular Banco de Dados derivado do código do Borland InterBase 6.0. Trata-se de uma ferramenta open-source e gratuita que está disponível para as mais diversas plataformas, seja Linux, Windows, Mac OS, FreeBSD ou Solaris. Como ele possui código aberto e não tem licença, é possível utilizá-lo em qualquer tipo de aplicação sem pagar nada por isso, mesmo em aplicações comerciais. A ferramenta é considerada madura porque sua tecnologia de base tem mais de 20 anos. 




Assim como nos artigos anteriores que escrevi sobre Linux, estou considerando que o servidor está devidamente instalado com a distribuição Debian GNU/Linux (ou seus derivados, como o Ubuntu). A primeira etapa consiste na instalação do pacote denominado firebird2.5-superclassic para que o Linux possa ser posteriormente configurado como servidor de banco de dados para aplicações clientes. Essa tarefa é simples e rápida através do APT:

root@Linux:/# apt-get update
root@Linux:/# apt-get install firebird2.5-superclassic

Obs.: O Firebird está disponível nas arquiteturas SuperClassic (firebird2.5-superclassic) e Classic (firebird2.5-classic). Vamos utilizar a arquitetura SuperClassic porque ela é mais indicada para uso em máquinas SMP (múltiplos núcleos de processamento). 

Durante a instalação do Firebird será aberto um diálogo para definir uma nova senha para o usuário padrão SYSDBA, sendo que frequentemente essa senha é masterkey. Essa senha pode ser redefinida a qualquer momento através do comando abaixo:

root@Linux:/# dpkg-reconfigure firebird2.5-superclassic

Feito isso, o Firebird já deve estar devidamente instalado e em execução no servidor, embora ainda não esteja permitindo acessos remotos através da rede. Para verificar se o serviço está em execução, basta utilizar o comando abaixo. Caso o administrador queira parar ou iniciar o serviço manualmente, esse mesmo comando pode ser utilizado alterando o parâmetro status por start (iniciar) ou stop (parar).

root@Linux:/# service firebird2.5-superclassic status

Apenas a título de observação, outra forma de verificar se o serviço está no ar é localizar manualmente os processos em execução no servidor, particularmente observando os processos denominados fb_smp_server e fbguard. O processo fbguard é um monitorador que protege a execução do servidor (fb_smp_server), de forma que o guardião automaticamente executa uma nova instância do processo servidor em caso de falha. 

root@Linux:/# ps aux | grep fb

(...) Exemplo de Saída do Comando

firebird  1064  (...) /usr/sbin/fbguard (...)
firebird  1065  (...) /usr/sbin/fb_smp_server
root      1226  (...) tty1 (...) grep fb

Depois de instalado, o arquivo de configuração do Firebird fica localizado em /etc/firebird/2.5/firebird.conf, sendo bem documentado e organizado em diferentes seções para facilitar sua configuração. Por padrão o servidor Firebird somente permite acesso a partir da máquina local (localhost) e é executado na porta 3050/TCP. Para permitir o acesso remoto ao servidor através de outras máquinas na rede, é necessário localizar e comentar a seguinte linha no arquivo de configuração do firebird:

###--- em /etc/firebird/2.5/firebird.conf
#RemoteBindAddress = localhost

Obs.: O acesso através da rede não irá funcionar se existir algum firewall no servidor ou mesmo no meio do caminho que esteja bloqueando comunicação na porta 3050/TCP. 

Uma vez que o Firebird esteja devidamente instalado e em execução, é possível criar novas bases de dados ou mesmo instalar o pacote com exemplos para testar a conexão remota. Através do comando abaixo utilizaremos o APT para instalar o pacote com exemplos prontos do Firebird. Na sequência podemos acessar o diretório /usr/share/doc/firebird2.5-examples/examples/empbuild para descompactar o banco de exemplo denominado employee.fdb.gz. Depois de descomprimir o banco de exemplo é necessário alterar o proprietário para firebird:firebird e, por fim, vamos mover o arquivo para o diretório /var/lib/firebird/2.5/data/ onde normalmente ficam armazenadas as bases de dados do firebird em servidores Linux. 

root@Linux:/# apt-get install firebird2.5-examples firebird2.5-dev 
root@Linux:/(...)# cd /usr/share/doc/firebird2.5-examples/examples/empbuild/
root@Linux:/(...)# gunzip employee.fdb.gz
root@Linux:/(...)# chown firebird.firebird employee.fdb
root@Linux:/(...)# mv employee.fdb /var/lib/firebird/2.5/data/

Agora, além do servidor instalado e em execução, temos também um banco de dados (.fdb) localmente armazenado no servidor que pode ser acessado remotamente. Para testar se o banco de dados está funcionando através da rede, em qualquer estação cliente é possível instalar o gerenciador gráfico FlameRobin (http://www.flamerobin.org/). Seguindo o mesmo espírito do próprio Firebird, o FlameRobin é uma ferramenta open-source e gratuita, bastante leve e disponível para as mais diversas plataformas, seja Linux, Windows, Mac OS, FreeBSD ou Solaris. 

Façam seus testes...

Samuel.

quinta-feira, 15 de setembro de 2016

Configuração de Suporte a Multicast em Switches Catalyst

Olá Pessoal,

A maioria das aplicações existentes em uma rede de computadores segue o modelo de comunicação cliente/servidor, ou seja, através de uma comunicação unicast (de um para um) onde os pares envolvidos sempre são uma estação cliente e outra estação servidora. No entanto, também podem existir aplicações de natureza multicast com comunicação de um para muitos, por exemplo quando existe um servidor de origem responsável por gerar conteúdo de interesse de múltiplas estações clientes (não de todas). Alguns exemplos comuns de serviços de natureza multicast são: clusterização de servidores, treinamentos online via telepresença, soluções de vigilância com câmeras IP, ferramentas de monitoramento distribuído, aplicações multimídia (áudio/vídeo), etc...

Quando existe alguma aplicação de natureza multicast na empresa é necessário preparar a infraestutura de switches para lidar de maneira apropriada com esse tipo de tráfego para otimizar sua propagação, caso contrário os switches simplesmente irão encaminhar todo o tráfego de maneira broadcast para todas as suas interfaces, oferecendo desempenho ruim porque gera mais tráfego nos links da infraestrutura. Qualquer endereço desconhecido por um switch em sua tabela MAC que não possa ser propagado para um destinatário de maneira unicast (uma única interface) ou que não tenha sido configurado com o vínculo de portas em grupo para ser propagado de maneira multicast (múltiplas interfaces) faz com que a propagação do tráfego ocorra de maneira broadcast (para todas as interfaces).

Para exemplificar o procedimento de configuração do suporte a multicast nos switches Catalyst da Cisco, a figura abaixo ilustra um cenário com dois switches que fazem parte da infraestrutura de um ambiente qualquer. Nesse ambiente existe uma aplicação multicast originando conteúdo, além de 3 estações diretamente interessadas no consumo do conteúdo da aplicação servidora, ou seja, esse exemplo caracteriza uma comunicação multicast de um para muitos. 


Por padrão os switches Catalyst vem ativados com o recurso IGMP Snooping, o que permite que os grupos multicast sejam automaticamente detectados na rede através do protocolo IGMP, sem nenhuma configuração. No entanto, se não existir um roteador multicast que seja responsável por enviar queries IGMP na rede para indagar quais máquinas conectadas em quais portas dos switches têm interesse em formar um grupo multicast, então não é possível tirar proveito do recurso IGMP de maneira dinâmica sem nenhuma configuração nos switches da infraestrutura.

Obs.: Caso o leitor tenha interesse na configuração de um roteador multicast, recomendo a leitura de outros artigos no blog que abordam os protocolos PIM-DM e PIM-SM de roteamento multicast.

Nesse exemplo em que não existe um roteador multicast, há duas possíveis soluções para configurar os grupos multicast diretamente nos switches: (1) através do recurso IGMP Querier que é suportado apenas em alguns switches mais novos ou (2) através da configuração manual de quais portas representam um grupo para uma determinada aplicação.

A configuração do querier IGMP Querier nos switches é bastante simples:

Switch-A(config)# ip igmp snooping querier

Switch-B(config)# ip igmp snooping querier

Caso os switches não tenham suporte ao recurso anterior, a solução é fazer o mapeamento manual das interfaces que pertencem a um grupo multicast. É importante saber que no IPv4 todo tráfego destinado para o intervalo de endereços que varia de 224.0.0.0 até 239.255.255.255 (Classe D) representa um fluxo multicast, de forma que o endereço lógico da camada de rede é mapeado para um endereço físico da camada de enlace que é pré-definido pelo IEEE e tem o formato 01:00:5E:XX:XX:XX, sendo que o final representa os últimos 23 bits do endereço IPv4 (RFC 1112). Toda máquina que é origem de tráfego multicast encaminha seu conteúdo para um endereço IP multicast da Classe D que representa um grupo.

Obs.: É igualmente importante saber que no IPv6 os endereços iniciados em FF00::/8 representam um fluxo multicast, de forma que o endereço lógico da camada de rede é mapeado para um endereço físico da camada de enlace que é pré-definido pelo IEEE e tem o formato 33:33:XX:XX:XX:XX, sendo que o final representa os últimos 32 bits do endereço IPv6 (RFC 2464).

Essa lógica de agrupamento é implementada através das próprias aplicações servidora e cliente, ou seja, a aplicação servidora utilizará um endereço multicast para alcançar seus receptores, sendo que esse endereço pode estar fixado na lógica da aplicação ou pode ser configurado pelo usuário. Por sua vez, as aplicações clientes ingressam a máquina receptora no respectivo grupo multicast por meio da configuração automática de um endereço IP de multicast sem que o usuário tenha que fazer essa configuração de endereçamento indivualmente em cada máquina receptora. Dessa forma a máquina cliente passa a responder por 2 endereços IP, sendo um endereço unicast configurado pelo administrador (manualmente ou via DHCP) e outro endereço multicast automaticamente configurado pela aplicação cliente.

No exemplo proposto o endereço multicast utilizado pela aplicação servidora para alcançar os receptores é 239.239.239.239, de forma que o respectivo MAC multicast será 01:00:5E:6F:EF:EF. A configuração manual consiste em informar no switch da esquerda que as interfaces f0/1, f0/3 e g0/1, onde estão conectados dois receptores e um switch que possui outro receptor, devem ser associadas com o endereço MAC da aplicação multicast (01:00:5E:6F:EF:EF). Da mesma forma, no switch de direita basta informar que a interface f0/1 possui um receptor conectado e associá-la com o MAC da aplicação multicast. Os comandos necessários para realizar o mapeamento estático são listados abaixo:

Switch-A(config)# mac address-table static 0100.5e6f.efef vlan 1 interface g0/1 f0/1 f0/3

Switch-B(config)# mac address-table static 0100.5e6f.efef vlan 1 interface f0/1

Fica visível que o mapeamento manual das interfaces dos switches que pertencem a um determinado grupo multicast não é muito viável em ambientes grandes que possuem vários grupos multicast, ou seja, não é nada escalável. No entanto, se o ambiente é menor e não possui um roteador multicast ou se os switches não possuem suporte ao recurso querier do IGMP, então o mapeamento manual é a opção remanescente. 

Façam seus testes...

Samuel.

quarta-feira, 13 de julho de 2016

Configuração de MultiLink PPP em Roteadores Cisco

Olá Pessoal,

O MultiLink PPP (MLPPP) é uma tecnologia padronizada na RFC 1990 e na RFC 2686 que permite agregar múltiplos links físicos de longa distância (do tipo PPP) através de uma única interface lógica equivalente à soma das capacidades dos links individuais. Trata-se, portanto, de um recurso interessante para obter um link lógico de alta velocidade e com maior disponibilidade a partir de múltiplos links de baixa velocidade. Uma vez que o MLPPP requer configuração coerente em ambas as pontas com a informação de quais interfaces físicas devem ser logicamente agrupadas, não é possível utilizar esse recurso para agregar múltiplos links físicos que sejam providos por diferentes operadoras.

O pré-requisito óbvio para configurar MLPPP é a existência dos links físicos PPP. A configuração do MLPPP é bastante simples, já que basta criar uma interface virtual do tipo multilink que receberá o endereço IP da rede ponto-a-ponto, além de ser referenciada como grupo lógico em cada uma das interfaces físicas. Tomando por base a topologia ilustrada na figura acima, as configurações necessárias estão destacadas abaixo em amarelo. As demais configurações consistem no estabelecimento dos links PPP, assunto abordado em outro artigo intitulado "Configuração de Link WAN PPP em Roteadores Cisco"

R1(config)# username R2 password SENHA
R1(config)# interface s2/0
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication chap
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# no shut
R1(config-if)# interface s2/1
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication chap
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# no shut
R1(config-if)# interface multilink 1
R1(config-if)# ppp multilink
R1(config-if)# ip address 203.0.113.1 255.255.255.252

R2(config)# username R1 password SENHA
R2(config)# interface s2/0
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication chap
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
R2(config-if)# no shut
R2(config-if)# interface s2/1
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication chap
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
R2(config-if)# no shut
R2(config-if)# interface multilink 1
R2(config-if)# ppp multilink
R2(config-if)# ip address 203.0.113.2 255.255.255.252

Depois de realizadas as configurações do MLPPP, é possível observar que uma nova interface virtual do tipo multilink passa a compor a relação de interfaces do roteador. Também é possível observar na tabela de roteamento que a rede ponto-a-ponto entre os dois roteadores está diretamente conectada através da interface lógica multilink, ao invés das interfaces físicas do tipo serial.

R1# show ip route
Codes: (...)
Gateway of last resort is not set

     203.0.113.0/24 is variably subnetted, 2 subnets, 2 masks
C       203.0.113.2/32 is directly connected, Multilink1
C       203.0.113.0/30 is directly connected, Multilink1

O comando abaixo é específico para MLPPP e bastante útil para identificar quais interfaces físicas compõem o agrupamento lógico multilink, além de apresentar o status dessas interfaces. Nesse exemplo, é possível observar que ambas as interfaces físicas seriais estão operacionais.

R1# show ppp multilink 
Multilink1, bundle name is R2
  Username is R2
  Endpoint discriminator is R2
  Bundle up for 00:01:22, total bandwidth 3088, load 1/255
  Receive buffer limit 24000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 6 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x16 received sequence, 0x17 sent sequence
  Member links: 2 active, 0 inactive (max not set, min not set)
    Se2/0, since 00:03:25
    Se2/1, since 00:02:22
No inactive multilink interfaces

Para verificar a disponibilidade do agrupamento lógico, basta desativar qualquer uma das interfaces físicas seriais para simular um falha qualquer no link. Mesmo em caso de queda de um dos links físicos, a interface lógica se mantém disponível através do(s) outro(s) link(s) físico(s). Por exemplo, temos a seguinte saída após desativar a interface s2/1 em R2:

R1# show ppp multilink
Multilink1, bundle name is R2
  Username is R2
  Endpoint discriminator is R2
  Bundle up for 00:03:16, total bandwidth 1544, load 1/255
  Receive buffer limit 12000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 12 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x22 received sequence, 0x39 sent sequence
  Member links: 1 active, 1 inactive (max not set, min not set)
    Se2/0, since 00:05:20
    Se2/1 (inactive)
No inactive multilink interfaces

Façam seus testes...

Samuel.

terça-feira, 5 de julho de 2016

Configuração de Link WAN PPP em Roteadores Cisco

Olá Pessoal,

PPP (Point-to-Point Protocol) é uma tecnologia padronizada na RFC 1661 e que consiste em um conjunto de protocolos da camada de enlace (layer-2) para controle de links de longa distância. Assim como a tecnologia Ethernet possui protocolos adicionais de suporte no contexto das redes locais (por ex. STP), a tecnologia PPP possui vários outros protocolos complementares. As duas principais categorias de protocolos complementares são:

  • Link Control Protocol (LCP): Esse protocolo implementa as funções de controle em nível de enlace (layer-2) de maneira totalmente independente do protocolo de rede utilizado nas camadas superiores, afinal o PPP é independente da tecnologia de rede utilizada em layer-3. As funções de controle estão relacionadas a diversos aspectos da conexão que envolvem o estabelecimento, configuração e verificação do link, além da autenticação (opcional);

  • Network Control Protocol (NCP): Na realidade o NCP é uma categoria de protocolos de controle que contém vários sub-protocolos, de forma que cada sub-protocolo está associado com uma tecnologia de rede layer-3 específica. Exemplos comuns de sub-protocolos dessa categoria são o IP Control Protocol (IPCP), o IPv6 Control Protocol (IPv6CP) e o Cisco Discovery Protocol Control Protocol (CDPCP).

Outra característica importante do PPP é a autenticação das partes envolvidas na comunicação. No contexto de um link de longa distância (WAN), o processo de autenticação é importante para que as interfaces seriais de dois roteadores provem suas identidades antes de estabelecer o link. Dois protocolos de autenticação utilizados em conjunto com o PPP são o PAP e o CHAP, sendo que o procedimento de configuração de ambos é basicamente o mesmo. O PAP não é seguro porque faz o envio do usuário e da senha como texto simples (sem criptografia), enquanto que o CHAP é considerado mais seguro pela forma como faz a troca de mensagens entre as partes (hash MD5).

A topologia exibida na figura abaixo será utilizada para exemplificar a configuração de um link WAN PPP entre dois roteadores Cisco. Observem que propositalmente os dois roteadores serão configurados com endereços IP pertencentes a diferentes sub-redes, algo que a princípio faz parecer impossível a comunicação entre os dois roteadores. No entanto, a surpresa é que depois de configurado o link WAN PPP entre R1 e R2 a comunicação ocorre com sucesso. Por que isso acontece?


Antes de responder essa questão, vamos às configurações necessárias para estabelecer o link PPP. Um detalhe na configuração da autenticação é que em R1 deve ser criado um usuário na base local equivalente ao hostname de R2 e vice-versa. O nome do usuário a ser autenticado deve ser exatamente o nome de host que foi configurado no roteador da outra ponta, caso contrário a autenticação falhará.

R1(config)# username R2 password SENHA
R1(config)# interface s0/3/0
R1(config-if)# ip address 203.0.113.1 255.255.255.255
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication chap
R1(config-if)# no shut

R2(config)# username R1 password SENHA
R2(config)# interface s0/3/0
R2(config-if)# ip address 198.51.100.1 255.255.255.255
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication chap
R2(config-if)# no shut

Uma vez configurado o laboratório proposto, agora podemos voltar à discussão das razões pelas quais o ping entre os dois roteadores funciona mesmo quando as interfaces seriais são configuradas com endereços em diferentes sub-redes. Se utilizássemos o mesmo cenário para configurar uma WAN entre os roteadores R1 e R2 através de links seriais com encapsulamento HDLC (padrão), o ping não funcionaria com as duas interfaces seriais configuradas com endereços em sub-redes diferentes. Isso ocorreria porque os roteadores R1 e R2 não teriam uma rota diretamente conectada que fosse comum a ambos, ou seja, seria impossível direcionar a saída do tráfego ponto a ponto. 

Esse comportamento padrão muda bastante quando configuramos o encapsulamento para PPP, já que os protocolos de controle da categoria NCP são responsáveis por tratar automaticamente das informações de roteamento. No contexto do IPv4, o IPCP do PPP automaticamente adiciona uma rota de host (/32) apontando para o endereço IP do roteador vizinho. Essa característica pode ser observada nos destaques em amarelo das tabelas de roteamento listadas abaixo. 

Em R1 o PPP criou uma rota de host apontando para R2 (198.51.100.1/32):

R1> show ip route
Codes: (...) Códigos Omitidos

Gateway of last resort is not set

198.51.100.0/32 is subnetted, 1 subnets
C 198.51.100.1/32 is directly connected, Serial0/3/0
203.0.113.0/24 is variably subnetted, 2 subnets, 2 masks
C 203.0.113.0/30 is directly connected, Serial0/3/0
L 203.0.113.1/32 is directly connected, Serial0/3/0

R1> ping 198.51.100.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 198.51.100.1, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/8 ms

Em R2 o PPP criou uma rota de host apontando para R1 (203.0.113.1/32):

R2> show ip route
Codes: (...) Códigos Omitidos

Gateway of last resort is not set

198.51.100.0/24 is variably subnetted, 2 subnets, 2 masks
C 198.51.100.0/30 is directly connected, Serial0/3/0
L 198.51.100.1/32 is directly connected, Serial0/3/0
203.0.113.0/32 is subnetted, 1 subnets
C 203.0.113.1/32 is directly connected, Serial0/3/0

R2> ping 203.0.113.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.1, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/7 ms

Apesar de ser possível utilizar endereços em sub-redes diferentes, essa prática não é recomendada. Um problema decorrente dessa prática não recomendada é que não será possível executar protocolos de roteamento dinâmico entre R1 e R2, já que para formar a vizinhança de roteamento é necessário que os roteadores compartilhem a mesma sub-rede. Ou seja, sua rede não estará totalmente operacional mesmo que o resultado do ping seja um sucesso! Esse recurso do PPP  é denominado Peer Neighbor Route e pode ser manualmente desativado em sub-modo de configuração da interface serial através do comando "no peer neighbor route". Tenham cuidado com esse detalhe e procurem seguir as boas práticas que recomendam utilizar uma sub-rede /30 em links ponto-a-ponto.

Façam seus testes...

Samuel.