Mostrando postagens com marcador rede. Mostrar todas as postagens
Mostrando postagens com marcador rede. Mostrar todas as postagens

quarta-feira, 25 de janeiro de 2012

Bonding – Juntando interfaces de rede no Linux

Descrição do recurso
Conforme descrito na documentação do kernel do Linux, o driver bonding é utilizado para agregar múltiplas interfaces de rede em uma interface lógica única. Seu comportamento depende da necessidade e da estrutura física da rede. Então, apesar de ser uma tarefa bastante simples e bem divulgada, dificilmente encontra-se um artigo que cite o melhor modo para cada condição.

Principais modos de configuração
Há dois modos principais de configuração do bonding, sendo soma do link ou modo backup, chamados de balance-rr (balance round robin) e active backup respectivamente. Nesse link estão descritos absolutamente todas as configurações de bonding incluindo alguns exemplos de configuração distribuidos pelo arquivo, mas esse post tratará apenas dos modelos descritos anteriormente.

No modelo acima, um host soma duas interfaces físicas em uma interface lógica, que chamaremos de bond0. Uma das interfaces será conectada a um switch e a outra interface a outro switch. Nesse modelo explicitamente deseja-se tolerância a falhas, então baseado nisso pode-se assimilar esse modelo da infra-estrutura com o modo de configuração active-backup (1), devido ao fluxo de dados distinto, onde a segunda interface de rede entrará em ação somente em caso de falha da primeira.

* Se houver interconexão dos switches (ISL), é seguro optar por active-backup.
* Se os switches não forem interconectados e as redes forem completamente independentes, então deve-se utilizar o modo broadcast.

Íntegra em Suhanko
Leia Mais ►

quarta-feira, 30 de novembro de 2011

Calculando VLSM, como fazer subredes

Introdução
Muitas pessoas já ouviram falar sobre classes IP, são coisas estudadas no início da carreira de uma profissional que lida com rede de computadores, porém muita gente não sabe que hoje essas classes já não são algo fixo como antigamente, hoje você pode muito bem usar um IP classe A com máscara classe C, esse modelo é chamado de CIDR (Classless Inter-Domain Routing), aqui vou demonstrar o uso de VLSM (Variable Length Subnet Masks), máscaras de tamanho variável, ou máscaras complexas, como definir isso, como calcular, como saber quantas rede e quantos IP's, tudo de forma simples e direta.

Uma máscara IP é formada por um conjunto de quatro casas com até 3 números cada, por exemplo o 255.255.255.0, uma máscara classe C e bem provável a mais usada em redes internas, essas quatro casas de número são formadas por um cálculo de binários, quatro octetos, no caso da máscara citada seria 11111111.11111111.11111111.00000000, como se pode notar, um octeto só com "1" forma o 255 e um octeto com "0" forma o 0 da máscara, é através desse octeto que vamos calcular nossa máscara para que possa trabalhar com subnets.

O Cenário
Imagine um cenário comum, uma rede 192.168.1.0 e uma máscara 255.255.255.0, logo com isso, você terá uma rede que vai de 192.168.1.1 à 192.168.1.254 pois não podemos esquecer que o primeiro IP é o número da rede e o último é o endereço Broadcast, agora imagine que você quer ou necessita dividir essa rede em outra subredes, para que possam trabalhar de forma isolada uma da outra, aí começa nosso trabalho.

Calculando
Precisamos dividir essa faixa de IP em 3, então fazemos o seguinte

Subredes
Primeiro passamos a máscara para binário:

11111111.11111111.11111111.00000000

Agora fazemos o cálculo para descobrir de quantas subredes precisaremos, isso é feito da seguinte forma

O octeto é separado por valores em cada casa, sendo eles 128, 64, 32, 16, 8, 4, 2 e 1, esse valor é contado da esquerda para a direita, logo, se transformamos o primeiro "0" em "1" mais 2 bits na máscara, mais 4 e assim por diante, então usamos a fórmula "2^x -2 = x", ou seja, '2 elevado ao número de bits acrescentados menos 2 = x'.

11111111.11111111.11111111.11100000

Aqui foi acrescentado 3 bits a máscara na parte que se destina aos hosts, logo a fórmula seria 2^3-2=6, ou seja, temos então 8 subredes num total com 6 podendo ser usadas, já que não usamos a primeira nem a última.

Nossa máscara agora passar a ser 192.168.1 mais a soma dos três primeiros bits acrescentados à máscara, no caso formando 224, nossa máscara passa a ser 192.168.1.224 para todas as subredes. A forma em bits da máscara logicamente passa de 8+8+8 (/24) para 8+8+8+3 (/27).

Hosts
Agora já sabemos como chegar ao número correto para nossa máscara e quantas subredes serão geradas, temos que saber quantas hosts teremos em cada e de onde até onde cada uma irá, isso é feito da seguinte forma:

Repete-se a fórmula para subdividir a rede só que destas vez usando o número de "0", ou seja, o número de bits restantes para definir os hosts.

2^x - 2 = x, nesse caso, ao invés do primeiro "x" ser o número de 1 acrescentados, será o número de 0 restantes, sendo assim, no nosso caso temos 2^5 - 2 = 30, ou seja, um total de 32 IPs disponíveis mas que só podem ser usados 30 já que o primeiro é o número da rede e o último o de broadcast.

Faixa de rede
Outra coisa a saber é saber o alcance de cada rede, isso é feito observando o último bit ativo, que no nosso caso é o terceiro 1 do quarto octeto, ele corresponde ao número 32, logo nossa rede começara em 0 e terminará em 31, a próxima começara em 32 e terminará em 63 e será assim até o 255, lembre-se sempre que o "0" é contado, logo os 32 primeiros começam em 0 e terminam em 31.

192.168.1.0/27 - 192.168.1.31/27
192.168.1.32/27 - 192.168.1.63/27
192.168.1.64/27 - 192.168.1.95/27
192.168.1.96/27 - 192.168.1.127/27
192.168.1.159/27 - 192.168.1.191/27
192.168.1.223/27 - 192.168.1.255/27

Outras classes
Devo lembrar que esse método serve para qualquer faixa, porém se salienta que se você tem uma rede classe A por exemplo, que é por padrão em forma binária 1111111.0000000.0000000.0000000, e acrescentar 12 bits ativos nela fazendo-a passar para 1111111.11111111.11110000.0000000, a contagem o cálculo de hosts será 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, ou seja, 2046 hosts válidos.

O cálculo de subredes é o mesmo, no caso citado acima, o último bit ativo representa o 16, logo, a primeira rede iria por exemplo de 10.0.0.0/20 à 10.0.15.255/20 (máscara hexadecimal é 255.255.240.0), a segunda de 10.0.16.0/20 à 10.0.31.255/20, seriam 4096 redes nesse exemplo, sendo 4094 válidas.

Esse conteúdo está disponibilizado sobre a licença de uso - Tiu enhavo estas disponebla sur uza permesilo LiPE
Leia Mais ►

terça-feira, 25 de outubro de 2011

ICINGA - Monitorando máquinas remotas com NRPE

Primeiro temos que saber o que é o Icinga, caso não saiba Icinga é uma ferramenta de monitoramento de sistema e rede. Ele foi originalmente criado como um fork do aplicativo de monitoramento de sistema e rede Nagios em 2009, básico e simples assim, seu site oficial é www.icinga.org. 

Este é um mini tutorial que visa explicar a configuração do nrpe para monitorar maquinas remotas usando o icinga. Também levo em consideração que o seu icinga já se encontra instalado e configurado, pois nesse tutorial não vou aborda o mesmo. vamos lá então.

- Na máquina monitor temos que instalar os seguintes pacotes:

yum install nagios-nrpe nagios-plugins nagios-plugins-nrpe

Já com estes pacotes instalados vamos as seguintes configurações:

Queremos monitorar um host remoto de email por exemplo, então criamos o arquivo email.cfg e dentro deste arquivos vamos acrescentar as seguinte linhas.

define host{
use servers
host_name E-mail
alias E-mail Server 64x CENTOS 5.5
address 192.168.0.8
hostgroups Servidores
}

Acima definimos a configuração do host. Lembrando que levo em consideração que os outros arquivos já se encontram configurados, mas farei posteriormente um tutorial abordando sua configuração no icinga.

Agora essa é a parte que interessa. No mesmo arquivo email.cfg logo abaixo de onde você definiu o seu host a ser monitorado vamos acrescentar os serviços vou colocar 3 em específico.

define service{
use generic-service
host_name E-mail
service_description IMAP
check_command check_nrpe!check_imap
}

define service{
use generic-service
host_name E-mail
service_description FTP
check_command check_nrpe!check_ftp
}

define service{
use generic-service
host_name E-mail
service_description MYSQL
check_command check_nrpe!check_mysql
}

Como podemos ver, o segredo se encontra na linha check_command, ela é a responsável em fazer praticamente todo o trabalho, veja abaixo:

Mas antes tenho que explicar algo sobre o arquivo commando.cfg, veja abaixo:

define command{
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c $ARG1$
}

Essas linhas acima, quando o arquivo email.cfg é lido ele vai consultar o comando referente ao mesmo no arquivo commando.cfg, então observe que check_nrpe é o comando que consulta o script check_nrpe ( $USER1& = /usr/lib64/nagios/plugins/check_nrpe - lembrando que meu centos é 64bits ). Quando essa linha é consultada, ela vai buscar as informações no servidor remoto, ai você pergunta, mas como? vou explicar, observa abaixo.

Então vamos para a máquina email que eu defini o ip como 192.168.0.8, nesta máquina você tem que instalar os seguintes pacotes:

yum install nagios-nrpe nagios-plugins

Editando o arquivo de configuração /etc/nagios/nrpe.cfg e mudar as seguintes linha:

allowed_hosts=xxx.xxx.xxx.xxx

Nesse campo você coloca o host que vai poder consultar o nrpe da máquina remota, também existe outras configurações caso queira olhar, mas vou abordar somente o que interessa nesse tutorial, vamos lá.
Lembra dos serviços definidos no email.cfg, e no commando.cfg, pois é, ele vai buscar as informações nessa configuração do nrpe.cfg, veja baixo um exempl:

command[check_imap]=/usr/lib64/nagios/plugins/check_imap -H 127.0.0.1 -p 993 -S -w 5 -c 10
command[check_ftp]=/usr/lib64/nagios/plugins/check_ftp -H 127.0.0.1 -p 21 -w 5 -c 10
command[check_mysql]=/usr/lib64/nagios/plugins/check_mysql -H 127.0.0.1 -d postfix -u postfix -p 123456 -w 5 -c 10

O check_nrpe!check_mysql diz para buscar o check_mysql que está no arquivo de configuração nrpe.cfg da máquina remota que é no caso essa linha ( command[check_mysql]=/usr/lib64/nagios/plugins/check_mysql -H 127.0.0.1 -d postfix -u postfix -p 123456 -w 5 -c 10 ). lembrando que você tem que dar um start no serviço nrpe depois que ele for instalado ( /etc/init.d/nrpe start ) eu deixei o meu configurado na porta padrão 5666 tcp, caso queira mudar isso fique a vontade.

Abaixo vou mostrar a consulta feita pelo check_mysql:

[root@localhost ]# /usr/lib64/nagios/plugins/check_nrpe -H 192.168.0.8 -p 5666 -c check_mysql
Uptime: 2235554 Threads: 17 Questions: 14661155 Slow queries: 0 Opens: 22253 Flush tables: 1 Open tables: 64 Queries per second avg: 6.558

Bem tentei explicar de uma forma fácil, caso ainda tenha dúvida, comente no blog ou mande um email para linuxplue@gmail.com que farei o que for possível para esclarecer as dúvidas, então pessoal até a próxima.

Esse conteúdo está disponibilizado sobre a licença de uso - Tiu enhavo estas disponebla sur uza permesilo LiPE
Leia Mais ►

Postagens populares