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.