quinta-feira, 3 de setembro de 2015

Pontos de Troca de Tráfego na Internet do Brasil

Olá Pessoal.

Uma forma de promover o desenvolvimento da Internet em termos de conectividade e desempenho é através da implantação dos chamados Pontos de Troca de Tráfego (PTT), do inglês Internet eXchange Point (IXP). Por possuírem dezenas ou centenas de Sistemas Autônomos (membros) conectados, atualmente os PTTs têm um papel crítico no ecossistema da Internet. Os PTTs tiveram um papel muito importante na distribuição de tráfego durante a Copa do Mundo de 2014 e o esperado é que sejam importantes novamente durante os Jogos Olímpicos de 2016, uma vez que permitem uma melhor distribuição de tráfego nas proximidades do usuário final.

Origem dos PTTs na Internet

Desde 1987 até 1994 a operação do backbone da rede NSFNET era responsabilidade da National Science Foundation (NSF) que, a partir de 1992, deu início a um plano para transferir a operação do núcleo da Internet para o setor privado. Foi no contexto desse novo ecossistema comercial que surgiram três elementos importantes: (i) Network Service Providers (NSP), responsáveis pela operação do backbone; (ii) Network Access Points (NAP), para transportar tráfego entre os NSPs a partir de locais estratégicos nos EUA; e (iii) Routing Arbiter (RA), para coletar e propagar informações de roteamento nos NAPs (similar aos modernos Route Servers). A concepção dos PTTs nasceu ainda nessa época, uma vez que os NAPs foram criados para ser um ponto físico de conexão de vários NSPs. Ao longo dos anos os NAPs enfraqueceram porque eram mantidos por grandes operadoras que tinham interesses próprios, o que motivou a desconexão das demais operadoras. 

As grandes operadoras somente tinham interesse de se conectar diretamente (peering) com outras de mesmo nível, demonstrando pouco (ou nenhum) interesse no peering aberto com outras operadoras menores. Em 1999 a necessidade por circuitos ponto-a-ponto entre as grandes operadoras escalava linearmente e custava caro, além do fato de que algumas vezes as concessionários telefônicas levavam mais de um ano para entrar um circuito. Diante dessa situação as grandes operadoras perceberam que o estabelecimento de peering privado através de um PTT neutro era mais rápido e econômico, tornando esse modelo dominante na Internet atual. 

Como Funcionam os PTTs?

Por definição o PTT é uma infraestrutura compartilhada que é instalada em uma região para receber a conexão de Sistemas Autônomos (através de peering) com o objetivo principal de otimizar o desempenho da Internet ao manter a troca de tráfego mais localizada entre diferentes redes pertencentes a uma mesma região, diminuindo, assim, o número de saltos entre membros geograficamente próximos. 

Seu núcleo é bastante complexo em termos de quantidade de conexões porque hospeda centenas de membros, por isso requer equipamentos de alto desempenho capazes de processar altas taxas de pacotes por segundo (pps). Apesar dessa complexidade, sua arquitetura é simples de entender, uma vez que o o objetivo do PTT se resume a prover um ponto centralizado de conexão através de uma switching-fabric baseada em tecnologia Ethernet (camada 2), conforme observado na figura abaixo.




Uma vez fisicamente conectados no PTT, seus membros podem acordar em fazer o peering multilateral (aberto) com todos os demais membros ou o peering bilateral (privado) de natureza seletiva ou restritiva, sendo que as configurações para o anúncioe alcançabilidade de prefixos IP são realizadas por meio do protocolo BGP (RFC 4271), via sessão TCP na porta 179. Para minimizar a complexidade de configuração individual do peering entre todos os membros através de uma topologia full-mesh, são instalados elementros centrais denominados servidores de rotas (RS) na infraestrutura do PTT, de maneira que um Sistema Autônomo é capaz de trocar rotas com os demais membros através do estabelecimento de uma única sessão BGP com o RS (peering multilateral), conforme pode ser observado na figura acima.




PTTs na Internet do Brasil

O Brasil lidera a região da América Latina operando mais de metade de todos os PTTs do continente e segue um modelo de negócios interessante que pode insipirar outros países em desenvolvimento. No cenário nacional o projeto IX.br (também conhecido como PTTMetro) contempla todos os PTTs públicos em operação, sendo o PTT-SP o maior da América Latina com registros médios de troca de tráfego da ordem de 600 Gbps e picos de 800 Gbps. Atualmente o IX.br está entre os dez que mais trocam tráfego no mundo, sendo o quinto maior em número de participantes. A tabela abaixo traz uma síntese de alguns dos maiores PTTs públicos do mundo em que é possível observar o grau de relevância do IX.br.


Desde 2006 o Brasil saltou de apenas 4 PTTs para 25 em operação (vide mapa abaixo), com 16 novas localidades em estudo, especialmente nas regiões norte e centro-oeste que são mais carentes de conectividade. Segundo o NIC.br, atualmente há 45 candidatos interessados em hospedar os novos IXPs. O objetivo maior por trás do projeto de expansão do IX.br é melhorar o desempenho da Internet no país e atrair provedores de acesso e de conteúdo para essas áreas mais carentes de conectividade. 

Fonte: IX.br (http://ix.br)

O modelo de negócios do PTT pode ser de natureza privada (comum nos Estados Unidos) ou aberta (comum na Europa e no Brasil). Na maioria dos casos, inclusive no Brasil, o objetivo principal do PTT é prover um ambiente aberto e indiscriminatório de natureza pública para estimular a colaboração e melhorar a troca de tráfego, alavancando a qualidade da Internet na sua região de operação. 

Samuel.

Fonte: Samuel Henrique Bucke Brito, Mateus Augusto Silva Santos, Ramon dos Reis Fontes, Danny Alex Lachos Perez, Christian Esteve Rothenberg. "Anatomia do Ecossistema de Pontos de Troca de Trafego Publicos na Internet do Brasil". [Slides] In XXXIII Simposio Brasileiro de Redes de Computadores (SBRC). Vitoria, ES, Brazil. May 18-22, 2015.

terça-feira, 4 de agosto de 2015

Instalação do Linux ONL em Switches Bare Metal

Olá Pessoal.

Os switches bare metal, também conhecidos como caixas brancas, são switches em que o hardware e o software são vendidos separadamente, ou seja, é possível comprar simplesmente a caixa "vazia" (hardware) sem nenhum sistema operacional pré-instalado. Dessa maneira, pode-se optar por uma versão comercial ou mesmo distribuições gratuitas de um Sistema Operacional de Rede ou NOS, do inglês Network Operating System.

O Open Network Linux (ONL) é a distribuição Linux open-source mais tradicional que foi especificamente desenvolvida para ser instalada em switches bare metal. A vantagem de utilizar uma distribuição desenvolvida para caixas brancas é que ela vem carregada com drivers e funcionalidades específicas do hardware, como por exemplo suporte aos slots SFP (1GbE), SFP+ (10GbE), etc... Uma vantangem das caixas brancas abertas em relação ao tradicional modelo fechado das caixas pretas é que é possível personalizar via software as funcionalidades que o switch irá assumir, de maneira que a caixa pode executar funções de switch layer-2, de roteador layer-3, de firewall, etc.


O objetivo deste artigo é mostrar aos leitores os passos necessários para instalar o ONL em caixas brancas que sejam homologadas para operar com essa distribuição de NOS. Para fazer os testes de instalação do ONL tive acesso a um switch bare metal da Edge-Core, especificamente o modelo AS5600-52X, que se trata de um switch TOR (Top of Rack) para ambientes de Data Center que possui 48 portas 10GbE e 4 portas 40GbE. Esse equipamento, além de ser uma caixa branca bastante poderosa, é hardware homologado pela ONL. A relação completa de switches homologados pode ser encontrada no link abaixo:


A maioria dos switches bare metal homologados possuem o ONIE (Open Network Install Environment), um boot loader que deve ser utilizado para instalar o NOS desejado pelo usuário. Na prática o ONIE é um pequeno sistema operacional pré-carregado como firmware no switch para facilitar o processo de instalação do NOS desejado pelo administrador.

Há várias maneiras de instalar o ONL, seja localmente através do console (out-band) ou mesmo remotamente através da rede (in-band). Caso o leitor esteja interessado em outros métodos para instalar o ONL através da rede, recomendo a leitura da seguinte documentação: 


Nos testes em que fiz optei pela instalação local através do console, por isso estarei documentando esse processo que é mais rápido e mais fácil. Antes de começar é importante acessar o site do ONL (http://opennetlinux.org/binaries) para baixar os respectivos arquivos que sejam compatíveis com o processador do switch e copiá-los em um pen-drive. Para instalar o ONL são necessários dois arquivos, um com extensão .installer e outro .swi. No caso desse exemplo, utilizei os seguintes arquivos compatíveis com o processador FreeScale P2020 do AS5600-52X:

  • onl-271da8d-powerpc-all.2015.06.05.01.22.installer
  • onl-271da8d-powerpc-all-2015.06.05.01.22.swi

O primeiro passo é conectar o cabo serial de console no switch. Ao ligar o switch, na sequência do boot, basta pressionar <ENTER> para ativar o modo interativo do ONIE. Caso o usuário interrompa o processo de boot antes do seu término (o que pode acontecer por engano), basta digitar boot no prompt para que o boot seja continuado. Na sequência, basta montar a partição do pen-drive localmente e executar o script de instalação do ONL (destaque em amarelo).

** Installer Mode Enabled **

ONIE:/ # fdisk -l
(...) Saída Omitida: Identificar Partição do Pen-Drive
ONIE:/ # mount /dev/sdXX /mnt
ONIE:/ # cd /mnt
ONIE:/ # sh onl-271da8d-powerpc-all.2015.06.05.01.22.installer
 Open Network Installer running under ONIE.
 Installer Version: Open Network Linux e148b7a (powerpc.all,...)
 Detected platform: powerpc-...
 Installing in standalone mode.
 Unpacking Open Network Linux installer files...
 onl.powerpc-as5600-52x.loader
 (...) Saída Omitida

Obs.: Nos testes em que realizei com colegas da FEEC/Unicamp, tivemos um problema de nomenclatura do hardware observado na figura abaixo. O nome identificador da plataforma suportada pelo instalador disponível no site do ONL é powerpc-as5600-52x, mas o nome da plataforma nos novos switches AS5600-52X da EdgeCore é powerpc-accton-as5600-52x-r0. Para contornar esse problema optamos por parar o script de descoberta automática das imagens, alterar manualmente o nome da plataforma no arquivo /etc/machine.conf e, somente então, executar o instalador (.installer). Os comandos abaixo foram utilizados para realizar essa solução de contorno:

ONIE:/ # /etc/init.d/discover.sh stop
ONIE:/ # vi /etc/machine.conf 
(...) realizar alteração manual

Tela de Erro do Nome Identificador da Plataforma

A partir deste ponto todas as configurações do switch e suas interfaces são realizadas através do ONL que é uma distribuição Linux baseada em Debian, sendo que a conta padrão para realizar o primeiro acesso ao sistema consiste no usuário "root" e senha "onl", lembrando que é recomendada a alteração da senha logo no primeiro acesso. Vale o conhecimento prévio do administrador na principal distribuição Linux, principalmente nas ferramentas dos pacotes iproute2 (ex.: ip) ou net-tools (ex.: ifconfig, route, arp, etc), inclusive no que diz respeito à inserção de novos pacotes através do apt-get. É possível instalar o Quagga (ou BIRD) e tratar a caixa como um roteador com alta densidade de portas, assim como é possível programar novas funcionalidades.

Enfim, são várias as possibilidades! :-)

Samuel.

sábado, 1 de agosto de 2015

Atualização do Firmware IOS em Switches Cisco Catalyst

Olá Pessoal.

Em algum momento pode ser importante atualizar o firmware de um roteador ou switch da Cisco para carregá-lo com uma imagem mais recente do IOS, seja para manter os equipamentos da infraestrutura sempre com o firmware mais recente recomendado pela Cisco ou mesmo para o fim específico de correção de algum bug que esteja limitando a operação de alguma feature importante da caixa. Este artigo irá ajudar o leitor no processo de atualização do firmware de um Switch Cisco Catalyst 3560, lembrando que os mesmos passos servem como referência para atualizar outros modelos de switches e roteadores.


Etapa 1) Baixar a Nova Versão do Firmware

Antes de iniciar o processo de atualização do firmware é conveniente verificar a versão atual do IOS existente na memória flash switch, tarefa simples de ser realizada através dos comandos "show version" e "dir flash:". Na saída abaixo é possível observar que temos um Switch Catalyst WS-C3560-24PS (modelo) com a versão 12.2(37)SE1 do IOS. 

Switch# show version
(...) Saída Omitida

Switch   Ports  Model              SW Version              SW Image
------   -----  -----              ----------              ----------
*    1   26     WS-C3560-24PS      12.2(37)SE1             C3560-IPSERVICESK

Switch# dir flash: 
Directory of flash:/

    3  -rw-     8662192          <no date>  c3560-ipservicesk9-mz.122-37.SE1.bin
    2  -rw-       28282          <no date>  sigdef-category.xml
    1  -rw-      227537          <no date>  sigdef-default.xml
    4  -rw-        1096          <no date>  vlan.dat

64016384 bytes total (55097277 bytes free)

A última versão disponível e sugerida pela Cisco para esse modelo específico de switch é a 12.2(55)SE10, lançada em fev/2015. Nesse caso específico, iremos então baixar o arquivo "c3560-ipservicesk9-mz.122-55.SE10.bin". Através do site da Cisco, especificamente na opção Suporte|Downloads, é possível baixar a última versão de firmaware sugerida para o modelo específico do(s) switch(es) em produção. Ao baixar o firmware (extensão .bin) é importante anotar o resultado do hash MD5 fornecido nas informações do download. Depois que copiarmos a última versão do IOS no switch, seja através da rede ou mesmo localmente, realizaremos um procedimento de veriricação do hash MD5 para garantir que o arquivo não está corrompido e, somente então, seguiremos com a atualização do firmware. 

Obs.: Fique atento que cada modelo específico de switch terá diferentes versões do IOS e é importante ser cauteloso ao baixar as versões corretas antes de seguir com o procedimento de atualização do firmware.

Etapa Opcional) Remover a Antiga Imagem do IOS

Embora essa etapa não seja obrigatória, é comum a memória flash não ter muito espaço em equipamentos antigos. Nesse exemplo específico nossa memória flash tem espaço suficiente para armazenar a nova imagem que possui apenas 12.16MB, já que do total de 64MB estão livres 55MB. Mesmo assim, há situações em que é conveniente liberar algum espaço da flash antes de armazenar a última versão do firmware, procedimento que pode ser realizado com o comando "delete":

Switch# delete flash:/c3560-ipservicesk9-mz.122-37.SE1.bin
Switch# dir flash: 
Directory of flash:/

    2  -rw-       28282          <no date>  sigdef-category.xml
    1  -rw-      227537          <no date>  sigdef-default.xml
    4  -rw-        1096          <no date>  vlan.dat

64016384 bytes total (63759469 bytes free)

Obs.: CUIDADO ao realizar esse procedimento de remoção da imagem do firmware em uso, uma vez que o switch ficará inutilizado em caso de boot inesperado. Na próxima etapa iremos copiar a nova versão do firmaware na flash e atualizar a informação do caminho de boot para que o switch possa ser reinicializável novamente. Nesse exato momento estamos com uma "caixa fria" em nossas mãos! :-o É sempre mais seguro manter na flash ambas as versões em uso e a nova do IOS até que o procedimento de atualização do firmware esteja concluído, embora nem sempre seja possível...

Epata 2) Copiar o Firmware IOS no Switch e Atualizar o Caminho de Boot

Um método prático de copiar o novo firmware no switch é através de um servidor TFTP que pode ser instalado em alguma máquina administrativa que esteja operando como um repositório de firmwares na rede ou até mesmo temporariamente no próprio notebook do administrador. Caso o leitor não conheça o serviço TFTP, recomendo a leitura do artigo abaixo em que explico como utilizar TFTP para transferir arquivos de configuração para switches/routers, já que a transferência de binários segue a mesma lógica.


Switch# copy tftp: flash:
>Address or name of remote host? <Endereço IP do Servidor TFTP>
>source filename? c3560-ipservicesk9-mz.122-55.SE10.bin
>Destination filename? c3560-ipservicesk9-mz.122-55.SE10.bin

Para verificar se o firmware foi devidamente copiado:

Switch# dir flash: 
Directory of flash:/

    3  -rw-    12749374          <no date>  c3560-ipservicesk9-mz.122-55.SE10.bin
    2  -rw-       28282          <no date>  sigdef-category.xml
    1  -rw-      227537          <no date>  sigdef-default.xml
    4  -rw-        1096          <no date>  vlan.dat

64016384 bytes total (51010095 bytes free)

Agora chegou a hora de verificar se o firmware não foi corrompido durante o download da página da Cisco ou mesmo durante o processo de transferência para o switch. Realizaremos um procedimento de veriricação do hash MD5 para garantir que o arquivo não está corrompido, sendo que a sequência numérica resultante deve ser igual àquela informada na página da Cisco:

Switch# verify /md5 flash:/c3560-ipservicesk9-mz.122-55.SE10.bin
(...)
verify /md5 (flash:c3560-ipservicesk9-mz.122-55.SE10.bin) = dcdc5647204459ac65cef367c2cd84fb

A etapa mais IMPORTANTE é informar o caminho da nova imagem do firmware:

Switch(config)# boot system switch all flash:/c3560-ipservicesk9-mz.122-55.SE10.bin

Por fim, basta salvar as configurações e reinicializar nosso switch que agora é "bootável"! 
Assim temos uma "caixa quente" novamente! :-)

Switch# write mem
Switch# reload

Depois de reinicializado o switch podemos verificar o novo firmware em execução:

Switch# show version

(...) Saída Omitida

Switch   Ports  Model              SW Version              SW Image
------   -----  -----              ----------              ----------
*    1   26     WS-C3560-24PS      12.2(55)SE10            C3560-IPSERVICESK

É isso, tenham cuidado com os testes! ;-)

Samuel.

domingo, 26 de julho de 2015

Suporte a VLAN Trunk em Servidores Linux

Olá Pessoal.

Tradicionalmente utilizamos switches multi-layer ou roteadores quando precisamos fazer o roteamento inter-VLAN em ambientes que possuem múltiplas VLANs associadas com suas respectivas sub-redes, uma vez que essas caixas especializadas oferecem suporte nativo ao encapsulamento 802.1q (trunk). Em um dos artigos mais lidos do blog, intitulado "Configuração de Switch Multi-Layer", explico ao leitor como configurar um switch Cisco para essa finalidade, através da criação de interfaces virtuais vinculadas às suas VLANs, de maneira que essas interfaces podem ser configuradas com um IP que será o gateway de todas as máquinas membros da respectiva VLAN.

Essa mesma tarefa pode ser configurada em um servidor Linux, por isso a topologia apresentada abaixo será utilizada para exemplificar o processo de configuração de roteamento inter-VLAN no Linux. Assim como nos artigos anteriores, estou considerando que o roteador Linux 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 vlan para que, posteriormente, as configurações de rede do Linux ofereçam suporte à criação de interfaces lógicas roteadas (layer-3) do tipo VLAN. Essa tarefa é simples e rápida através do APT:

apt-get install vlan

Agora basta editar o arquivo de configuração das interfaces de rede que fica localizado em "/etc/network/interfaces". A partir da interface física eth0 (trunk 802.1q), criaremos duas novas interfaces lógicas denominadas eth0.100 (vlan100) e eth0.200 (vlan200).

###--- em /etc/network/interfaces

auto eth0
iface eth0 inet manual

   auto eth0.100
   iface eth0.100 inet static
      address 192.168.100.254
      netmask 255.255.255.0

   auto eth0.200
   iface eth0.200 inet static
      address 192.168.200.254
      netmask 255.255.255.0

Na sintaxe eth0.100 fazemos referência à interface física antes do ponto e, depois do ponto, fazemos referência ao número da VLAN vinculada à interface. É somente depois da instalação do pacote vlan que o Linux passa a reconhecer essa sintaxe. Uma alternativa válida seria utilizar uma convenção diferente de nomes em que fazemos referência direta à VLAN na denominação da interface em conjunto com o parâmetro vlan-raw-device para associá-la a sua respectiva VLAN. O exemplo abaixo traz a mesma configuração anterior com essa sintaxe alternativa:

###--- em /etc/network/interfaces

auto eth0
iface eth0 inet manual

auto vlan100
iface vlan100 inet static
   vlan-raw-device eth0
   address 192.168.100.254
   netmask 255.255.255.0

auto vlan200
iface vlan200 inet static
   vlan-raw-device eth0
   address 192.168.200.254
   netmask 255.255.255.0

Como o Linux não permite o roteamento entre sub-redes por padrão, é necessário instruir seu kernel a fazê-lo por meio de um dos comandos abaixos, lembrando que a primeira opção é volátil, ou seja, será perdida em caso de boot, enquanto que a segunda opção é persistente:

opção 1) echo "1" > /proc/sys/net/ipv4/ip_forward
opção 2) sysctl -w net.ipv4.ip_forward=1

Obs.: Vale ressaltar que as interfaces lógicas do tipo VLAN são diferentes das tradicionais sub-interfaces lógicas vinculadas às interfaces físicas. A criação de sub-interfaces lógicas é uma técnica simples de virtualização de interfaces físicas nativamente reconhecida pelo Linux, procedimento realizado através da sintaxe ethX:X. Por outro lado, o Linux torna-se capaz de interpretar cabeçalhos 802.1q (trunk) quando utilizamos o pacote vlan para criar interfaces lógicas roteadas do tipo VLAN (sintaxe ethX.X).

Façam seus testes...

Samuel.

quarta-feira, 15 de julho de 2015

Configuração de Agregação de Links no Linux

Olá Pessoal.

Um recurso bastante comum na interconexão de dispositivos da infraestrutura e também de servidores em redes de computadores é a agregação de links (ethernet bonding), técnica que permite a criação de uma interface lógica através do acoplamento de dois ou mais canais físicos. O resultado é que o novo canal lógico pode ter maior velocidade através da soma das vazões das interfaces físicas (load balancing), além de aumentar a disponibilidade da conexão por causa dos canais físicos redundantes (failover).

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 ifenslave para que, posteriormente, as configurações de rede do Linux ofereçam suporte à agregação de links. Essa terafa é simples e rápida através do APT:

apt-get install ifenslave

Agora basta editar o arquivo de configuração das interfaces de rede que fica localizado em "/etc/network/interfaces". Criaremos uma nova interface lógica denominada bond0 que estará vinculada às interfaces físicas eth0 e eth1, conforme destacado em amarelo nas configurações abaixo

###--- em /etc/network/interfaces

auto eth0
iface eth0 inet manual

auto eth1
iface eth1 inet manual

auto bond0
iface bond0 inet static
    address 192.168.0.1
    netmask 255.255.255.0
    slaves eth0 eth1
    bond_mode balance-rr
    bond_miimon 100
    bond_downdelay 200
    bond_updelay 200

Em termos de configuração, é simples assim! É interessante destacar que existem vários modos de operação na agregação de links para prover serviços como disponibilidade (failover) ou balanceamento de carga (load balancing). Na configuração do campo bond_mode (destaque em azul) é possível informar os números ou nomes (entre parênteses) dos modos de operação explicados na sequência.

  • modo 00 (balance-rr) - trata-se da opção padrão em que os pacotes são transmitidos sequencialmente de maneira alternada (round-robin) entre todas as interfaces físicas, provendo ambas as funcionalidades de load balance e failover;
  • modo 01 (active-backup) - nesse modo de operação apenas uma interface física é utilizada para transmissão de pacotes, sendo que as demais ficam em espera (stand-by) até que a interface ativa venha a cair, provendo apenas a funcionalidade de failover;
  • modo 02 (balance-xor) - os pacotes são transmitidos em todas as interfaces físicas com base nos resultados de uma operação xor (ou exclusivo) entre os endereços físicos (MAC) de origem e destino, provendo ambas as funcionalidades de load balancing e failover;
  • modo 03 (broadcast) - transmite repetidamente  uma cópia dos pacotes em todas as interfaces físicas, provendo apenas a funcionalidade de failover;
  • modo 04 (802.3ad) - utiliza o protocolo dinâmico LACP (IEEE 802.3ad) para negociar automaticamente com o dispositivo vizinho (diretamente conectado) se é possível criar uma agregação lógica das interfaces físicas;
  • modo 05 (balance-tlb) - trata-se de uma forma especial de balanceamento de carga que não depende de nenhuma configuração no switch diretamente conectado, onde o tráfego de saída é distribuído entre as interfaces físicas (com base na carga de cada uma) e o tráfego de entrada chega em uma única interface ativa;
  • modo 06 (balance-alb) - trata-se de uma forma especial de balanceamento de carga que não depende de nenhuma configuração no switch diretamente conectado, onde ambos os tráfegos de saída e entrada são distribuídos entre as interfaces físicas;

A configuração da agregação de link no switch também deve ser devidamente realizada, dependendo do modo utilizado. A agregação lógica  de links físicos em switches Cisco Catalyst é denominada Port-Channel (ou Ether-Channel) e bastante simples de ser realizada manualmente, por exemplo através dos comandos abaixo para criar uma nova interface lógica po1 (f0/1 + f0/2).

Switch(config)# interface range f0/1 - 2
Switch(config-if)# channel-group 1 mode on

Obs.: Caso o Linux tenha sido configurado com bond_mode 802.3ad (modo 4), recomendo a leitura abaixo para configuração do protocolo dinâmico LACP (IEEE 802.3ad) no switch.

http://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/sbcelacp.html#wp1053817

Façam seus testes...

Samuel.

sexta-feira, 10 de julho de 2015

Configuração Básica do SAMBA em Servidores Linux

Olá Pessoal.

O SAMBA é uma suíte de ferramentas instaladas em um servidor Linux que permite a integração de ambientes heterogêneos através da comunicação entre sistemas Linux e Windows, viabilizando serviços de diretórios no Linux (controlador de domínio), o controle de acesso dos usuários, compartilhamento de arquivos e de impressoras, etc. A integração é possível porque em ambos os sistemas a comunicação é baseada no protocolo SMB/CIFS (Server Message Block / Common Internet File System).


# Configuração do Servidor SAMBA

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 servidor de arquivos para clientes Windows e Linux. Essa tarefa é simples e rápida através do APT:

root@smb-server:/# apt-get install samba

Para exemplificar o processo de compartilhamento de diretórios no servidor com os demais clientes da rede, vamos criar os diretórios "/smb/publico" (acesso total público) e também "/smb/privado" (acesso restrito ao usuário shbbrito):

root@smb-server:/# mkdir -p /smb/publico
root@smb-server:/# chown nobody.nogroup /smb/publico
root@smb-server:/# chmod 777 /smb/publico

root@smb-server:/# mkdir -p /smb/privado
root@smb-server:/# chown shbbrito.shbbrito /smb/privado
root@smb-server:/# chmod 750 /smb/privado

O arquivo de configuração do SAMBA fica lozalicado em "/etc/samba/smb.conf", sendo bem documentado e organizado em diferentes seções para facilitar sua configuração. O simples compartilhamento de diretórios (objeto deste artigo) é realizado através da inserção de novos diretórios entre colchetes na seção denominada "Share Definitions", como pode ser observado no exemplo abaixo.

###--- em /etc/samba/smb.conf

(...) Conteúdo Omitido

workgroup = SAMBA
interfaces 192.168.221.11/24 ethX
bind interfaces only = yes
server role = standalone server
passdb backend = smbpasswd

######### Share Definitions

[smb-publico]
   comment = "Diretorio Publico"
   path = /smb/publico
   public = yes
   only guest = yes
   writable = yes
   printable = no

[smb-privado]
   comment = "Diretorio Privado (shbbrito)"
   path = /smb/privado
   public = no
   only guest = no
   valid users = shbbrito
   valid users = @shbbrito
   writable = yes
   printable= no

Obs.: Caso não haja integração do SAMBA com nenhum serviço de diretórios para fins de autenticação dos usuários, como é o caso deste exemplo em que o servidor é standalone, é necessário: (1) criar o arquivo de usuários reconhecidos pelo serviço, (2) limitar seu acesso para somente leitura e (3) adicionar os usuários que também devem existir previamente no servidor Linux.

root@smb-server:/# touch /etc/samba/smbpasswd
root@smb-server:/# chmod 644 /etc/samba/smbpasswd
root@smb-server:/# smbpasswd -a nome_do_usuario
Password: *****
Re-Type Password: *****

Depois de realizadas as configurações, basta (re)iniciar o serviço SAMBA:

root@smb-server:/# service smbd restart

# Configuração do Cliente Windows

Na realidade não há nenhum segredo a ser detalhado nessa seção. O acesso aos compartilhamentos do servidor SAMBA através de estações clientes que estejam executando alguma versão do Windows pode ser feito através da execução (atalho Windows+R) do endereço ou nome do servidor (\\192.168.221.11). Também é possível fazer o acesso direto a um diretório específico (\\192.168.221.11\smb-publico\) e mapear unidades de rede para facilitar o acesso do usuário.

# Configuração do Cliente Linux

De forma muito similar aos clientes Windows, em clientes Linux que tenham um ambiente gráfico é possível localizar os compartilhamentos através da simples navegação na rede ou mesmo através da navegação manual ao servidor, por ex.: smb://192.168.221.11. Na ocasião do acesso através de clientes que não tenham uma interface gráfica, o acesso pode ser realizado através da ferramenta smbclient.

01. apt-get install smbclient
02. smbclient -L 192.168.221.11
03. smbclient //192.168.221.11/smb-publico -U nome_usuario

Na linha 01 estamos instalando o cliente SAMBA (smbclient), caso não haja nenhum instalado na máquina. O comando da linha 02 (parâmetro -L) pode ser utilizado para visualizar os compartilhamentos disponibilizados pelo servidor que responde por um determinado nome ou IP. O acesso ao diretório propriamente dito é realizado na linha 03, sendo que na sequência o usuário será direcionado para um prompt SMB similar ao prompt do FTP. No prompt SMB o comando get é utilizado para baixar um arquivo remoto na máquina local, enquanto que o comando put é utilizado para subir um arquivo local no servidor remoto. Para obter mais detalhes dos outros comandos e da ferramenta smbclient, recomendo a leitura do seu manual através do comando "man smbclient".

Uma alternativa à manipualação dos arquivos compartilhados através do smbclient é montar localmente na máquina cliente o diretório remoto compartilhado pelo servidor. Esse procedimento pode ser realizado através do seguinte comando:

mount -t cifs //192.168.221.11/smb-publico /home/shbbrito/smb-publico -o username=shbbrito

Façam seus testes...

Samuel.

quinta-feira, 2 de julho de 2015

Configuração de Servidor de Arquivos NFS no Linux

Olá Pessoal.

O Network File System (NFS) é um sistema de arquivos desenvolvido pela Sun Microsystems na década de 80 para viabilizar o compartilhamento de arquivos entre sistemas Unix de diferentes naturezas, inclusive o Linux. O interessante do NFS é sua simplicidade de operação no servidor e principalmente no cliente. Para os clientes NFS basta montar os diretórios compartilhados, da mesma maneira que é realizado o processo de montagem de qualquer outra unidade de disco, ou seja, os diretórios compartilhados passam a ser montados e visualizados localmente no cliente.
# Configuração do Servidor NFS

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 dos pacotes denominados nfs-kernel-server e nfs-common para que o Linux possa ser posteriormente configurado como servidor de arquivos. Essa tarefa é simples e rápida através do APT:

root@nfs-server:/# apt-get install nfs-kernel-server nfs-common

Para exemplificar o processo de compartilhamento de diretórios no servidor com os demais clientes da rede, vamos criar os diretórios "/nfs/publico" (modo padrão com usuário nobody e grupo nogroup) e também "/nfs/privado" (modo restrito):

root@nfs-server:/# mkdir -p /nfs/publico
root@nfs-server:/# chown nobody:nogroup /nfs/publico
root@nfs-server:/# chmod 007 /nfs/publico

root@nfs-server:/# mkdir -p /nfs/privado
root@nfs-server:/# chown user:group /nfs/privado
root@nfs-server:/# chmod 750 /nfs/privado

As configurações do servidor NFS são realizadas no arquivo de configuração que fica localizado em "/etc/exports". Na sequência trago as linhas de configuração necessárias para compartilhar os dois diretórios criados na etapa anterior:

###--- em /etc/exports
/nfs/publico   192.168.221.21(rw,sync,no_root_squash)   192.168.221.0/24(ro,sync)
/nfs/privado   192.168.221.21(rw,sync,no_root_squash)

Obs.:  Nas configurações acima estamos considerando que o servidor NFS possui o endereço IP 192.168.221.11. A sintaxe das linhas de configuração do arquivo exports é bem simples: a primeira coluna contém o diretório local que será compartilhado, enquanto que a segunda coluna contém o endereço ou nome de uma máquina cliente (ou toda a rede) acompanhado das suas opções entre parênteses. É possível criar várias colunas fazendo referência a diferentes máquinas clientes, como fizemos em relação ao diretório /nfs/publico que tem acesso de leitura e escrita (rw) para o host 192.168.221.21 e acesso somente leitura (ro) para as demais máquinas da rede 192.168.221.0/24. A opção no_root_squash diz que o compartilhamento poderá ser editado pelo root remoto (cliente) com os mesmos privilégios do root local (servidor).

Por fim, basta reiniciar o serviço NFS para validar as novas configurações.

root@nfs-server:/# service nfs-kernel-server restart

# Configuração do Cliente NFS

Nas estações o cliente NFS pode ser facilmente instalado através do APT:

root@nfs-client:/# apt-get install nfs-common

É necessário criar no cliente o(s) diretório(s) locais em que os compartilhamentos do servidor serão montados. Pode ser utilizado qualquer diretório, inclusive o /home dos usuários...

root@nfs-client:/# mkdir -p /mnt/publico
root@nfs-client:/# mkdir -p /mnt/privado

Em seguida, basta montar os compartilhamentos do servidor nos respectivos diretórios que criamos localmente na estação cliente, de maneira bastante similiar o processo de montagem de discos que era comumente utilizado para acessarmos mídias extenas há alguns anos atrás (e ainda hoje), quando não havia a montagem automática! ;-)

root@nfs-client:/# mount 192.168.221.11:/nfs/publico /mnt/publico
root@nfs-client:/# mount 192.168.221.11:/nfs/privado /mnt/privado

Pronto! Agora a estação cliente já tem acesso a todos os arquivos compartilhados no servidor a partir dos diretórios montados localmente. É possível verificar os pontos de montagem compartilhados por meio das saídas dos comandos "df -h" e "mount". Abaixo trago um exemplo da saída de outro comando útil que pode ser utilizado no cliente para descobrir quais diretórios estão sendo compartilhados pelo servidor:

root@nfs-client:/# showmount -e 192.168.221.11
Export list for 192.168.221.11:
/nfs/privado 192.168.221.21
/nfs/publico 192.168.221.0/24,192.168.221.21

# Montando os Compartilhamentos Automaticamente no Boot

Uma alternativa ao processo manual de configuração dos pontos de montagem compartilhados nos clientes é alterar o arquivo de configuração "/etc/fstab" para que as montagens sejam realizadas durante o boot. Para exemplificar esse processo em relação ao diretório público que criamos anteriormente, podemos incluir a linha abaixo ao final desse arquivo:

[...] Saída Omitida
192.168.221.11:/nfs/publico  /mnt/publico   nfs   defaults   0   0

Acho que não é necessário dizer que as montagens também poderiam ser realizadas através de scripts inicializados automaticamente. Façam seus testes...

Samuel.