00000001 + 00000001 = 00000011 texto alternativo http://locobox.googlepages.com/red_x_round.png

Equívocos sobre redes *

Hora de confessar! ... 'em algum momento' você pensou que sabia alguma coisa, e acabou não sendo correta ou totalmente incorreta devido a um equívoco sobre o assunto.

Vamos criar uma boa lista de conceitos errôneos populares, novatos E até alguns administradores de TI experientes explicitamente sobre redes. Minha esperança é construir um despejo cerebral muito útil para servir como um bom recurso para os membros desta comunidade.

Começarei com um exemplo extremamente óbvio (os itens com mais votos em cima estarão no topo) :

• Todos os endereços que começam com 169 são provenientes do sistema de failover APIPA

  Somente 169.254.0.0/16 é reservada para a atribuição APIPA quando o SO não consegue encontrar um endereço atribuído para uma interface de rede ( leia-se: rfc3927 ).

***** Não deve ser confundido com "Erros cometidos por administradores de sistemas"

Mito: Permitir que o ICMP seja inseguro.

Este é um problema meu, e é bastante difundido para causar problemas significativos na Internet. Além dos diagnósticos úteis que todos conhecemos e amamos, há o Path MTU Discovery e outras coisas que são interrompidas quando o ICMP é bloqueado.

Algumas pessoas têm crenças religiosas sobre endereços IP permitidos e não permitidos. Ontem, vi em uma das respostas aqui que 'os endereços IP que terminam em 0,0 ou 0,255 são inválidos', o que é totalmente errado.

Outros ainda pensam que temos apenas sub-redes do tamanho A, B, C, enquanto o CIDR governava o mundo por um bom tempo.

Alguns afirmam que desativar as respostas do ICMP tornará minha estação de trabalho invisível em seu segmento de LAN, o que não é verdade. Você ainda pode enviar solicitações de ARP e, na maioria dos casos, a máquina enviará uma resposta de ARP, embora tenha um firewall em nível de IP em execução.

Outros dizem que as sub-redes privadas - 192.168.0.0/16 ou 10.0.0.0/8 não são "roteáveis" - o que está errado novamente.

As pessoas ficam realmente surpresas quando descobrem como a saturação de upload afeta suas velocidades de download. Isso depende muito dos algoritmos de enfileiramento nas duas extremidades do gargalo, mas no caso de conexões ADSL típicas, o upload pode afetar significativamente o download.

No lado engraçado: alguns ainda pensam que "a Internet é uma série de tubos" .

Todas as conexões à Internet são criadas da mesma forma, ou seja, a velocidade de download é a única coisa que importa

"Acabei de descobrir o que é um T1, você não sabe que meu cabo Comcast em casa é 6x mais rápido que a nossa conexão no trabalho? Por que não temos isso aqui?"

Isso não acontece mais, mas chegou ao ponto em que prefiro engolir grampos do que tentar explicar um SLA para mais um profissional de marketing. (OK, eu tive a mesma pergunta quando eu era um suporte de estação de trabalho, admito!)

James Gosling cita Peter Deutsch com crédito pelas oito falácias da computação distribuída :

Essencialmente, todo mundo, quando cria um aplicativo distribuído, faz as oito suposições a seguir. Todos provam ser falsos a longo prazo e causam grandes problemas e dolorosas experiências de aprendizado.

1. A rede é confiável
2. Latência é zero
3. A largura de banda é infinita
4. A rede está segura
5. A topologia não muda
6. Existe um administrador
7. O custo de transporte é zero
8. A rede é homogênea

Eu os tenho na parede do meu cubo de frente para o corredor. Às vezes, sinto que tropeço em mais de uma delas por dia .

Um velho, mas um bonzinho,

• BPS (bits por segundo) e BAUD são a mesma coisa - o que não são. BAUD é a taxa de símbolos. Em muitos sistemas, os símbolos codificam cada um 2 ou mais bits. por exemplo,

  + 2v = 11
  + 1v = 10
  -1v = 01
  -2v = 00

Na prática...

802.11A! = 54 Mbit / s, 802.11A ~ 27 Mbit / s

802.11B! = 11 Mbit / s, 802.11B ~ 5 Mbit / s

802.11G! = 54 Mbit / s, 802.11G ~ 22 Mbit / s

Eu odeio quando a rede é responsabilizada por algo com um aplicativo lento.

Quando tudo funcionar, exceto o Outlook, pare de atualizar o ticket para a equipe de rede dizendo que a rede está inoperante. Trabalhadores ignorantes do suporte técnico são a desgraça da existência de muitos administradores.

Fazer coisas no "hardware" é sempre melhor do que fazer no "software".

(o que leva à pergunta óbvia de onde se desenha a linha entre os dois, afinal, ou se há mesmo uma boa distinção?)

Que "MBps" e "mbps" são intercambiáveis. Mesmo se eu pudesse discernir contextualmente que 'milibits' não são uma unidade de medida válida, ainda há um fator de diferença de 8 entre os dois.

E nem me inicie em mebibits.

Em um ambiente de LAN corporativa, muitas pessoas ainda estão sob a suposição de que o roteamento entre vlans é mais lento que o switch. Com os modernos switches de hoje, tanto o switch quanto o roteamento são manipulados em hardware que pode processar / encaminhar esses pacotes na mesma velocidade.

A idéia de que os dispositivos de hardware dedicados são sempre melhores, mais confiáveis ​​e com melhor desempenho do que o hardware de commodity e / ou PC - na prática , com os custos atuais.

É basicamente o que a Cisco quer que você acredite; Certamente, o NPE no chassi do roteador possui apenas um processador ARM de ~ 300 MHz, mas possui todos esses ASICs (Circuitos Integrados de Aplicação Específica) apenas para encaminhamento rápido de pacotes, pesquisas de roteamento FIB e assim por diante.

Embora isso possa ser verdade, e eu geralmente faço favor usando engrenagem proprietária desse tipo de roteadores e switches para uma variedade de razões administrativas e MTBF-relacionados, o fato é que na era de 3 GHz e 8 GB de RAM, muitas vezes a presença de ASICs e CAM simplesmente não importa - o PC ainda pode fumar esse roteador. Claro, todo o material é feito na CPU em vez de ser excluído do hardware dedicado e, claro, tudo está em processos sujeitos aos estragos de um ambiente de agendamento de espaço do usuário em um sistema operacional de uso geral, mas quando você tem 20x a potência da CPU, às vezes não importa - ainda sai muito à frente e muito mais barato.

Aprendi isso novamente recentemente, ao lidar com uma flecha PIX bastante sofisticada para aumentar as cargas de processamento de pacotes em um ambiente crescente de VoIP (roteadores de pacotes por segundo altos prejudicam muito mais do que a taxa de transferência geral em si, e os fluxos de áudio VoIP consistem em muito grandes quantidades de pacotes muito pequenos); o firewall do Linux que eu configurei como uma medida paliativa para o roteamento entre VLAN, entretanto, expulsou essa coisa da água.

O mesmo vale para BGP. Ainda há um debate intenso no mundo da Cisco sobre as especificações mínimas de roteadores necessárias para manter uma ou mais visualizações completas de BGP da tabela de roteamento IPv4 cada vez maior, uma vez que muitos modelos de roteador geralmente são capazes disso, caso não fiquem na RAM . Bem, você sabe, o Quagga e um servidor Linux sólido com uma grande NIC e ajustes de E / S de baixa interrupção podem fazer maravilhas. :-)

Essa duplicação de endereço MAc não é possível. É, é muito improvável.

O equívoco de que usar a conexão sem fio significa que o acesso à Internet é muito mais lento porque mostra 54 MB / s, enquanto o uso de uma conexão Ethernet mostra 100 MB / s.

Escusado será dizer que foi difícil explicar ao usuário que era apenas a velocidade da rede local e, na verdade, a velocidade da Internet no site era de apenas 8 mbps / 900 KB / s.

Ou, como alternativa, os usuários que exigem que você forneça uma conexão de banda larga, quando você diz que a rede sem fio que eles estão usando está conectada a uma conexão de Internet de banda larga, eles exclamam "Não, eu quero dizer o cabo azul!"

O tipo de cabo não importa para a rede, desde que seja profissionalmente cravado. Isso vem de um administrador se perguntando por que os computadores novos ainda acessam a Internet lentamente com seus adaptadores 100Base-T. O cabo de rede era Cat-3 IIRC.

O equívoco de que uma rede comutada Ethernet == uma rede segura. Não faz.

Além da presença onipresente de ferramentas de envenenamento por arp como 'Cain & Abel' e seus tipos, o fato de a tabela CAM expirar de tempos em tempos (padrão 5 minutos em um switch Cisco ) e assim inundar o tráfego unicast como um hub se traduz em vazamento de pacotes e, portanto, possível vazamento de informações.

Você pode alterar o valor do tempo limite nos comutadores gerenciados para compensar a quantidade de inundação que deseja permitir, mas, como faz parte do funcionamento da comutação Ethernet, não é possível atenuá-lo completamente.

Você precisa de um cabo cruzado para conectar 2 computadores com Ethernet de gigabit. Você não! Patch faz o truque!

Mito: dobrar os bps de um link dobra a taxa de transferência útil.

Como em muitos mitos, isso pode ser verdade em algumas circunstâncias limitadas, mas ignora a latência do link e os limites de desempenho dos sistemas finais e dos protocolos.

Aumentar os bps reduz o tempo que leva para um sistema colocar os dados no link, não faz com que os dados se movam ao longo do link mais rapidamente. O tempo para o início do primeiro bit chegar ao outro extremo é o mesmo de antes, mas o atraso até a chegada do último bit é reduzido.

Eu tenho alguns mitos relacionados a redes privadas (10.xxx, 192.168.xx, etc.).

Mito 1: IPs privados nunca podem aparecer na rede pública. Portanto, não é possível que um IP privado que não seja o seu próprio apareça em, por exemplo, uma listagem de traceroute ou os cabeçalhos SMTP "Recebidos por".

Mito 2: não é possível para um servidor DNS voltado para a Internet distribuir endereços IP de rede privada.

Ambos os mitos decorrem do mesmo equívoco: que os IPs privados são realmente privados e que nunca se misturam com os IPs públicos. Acredito que a especificação diz apenas que IPs privados nunca serão roteados na rede pública. Ou seja, se você tentar encontrar a rota para algum IP privado aleatório (supondo que não esteja na sua própria rede), não chegará a lugar algum.

Mas isso não impede que IPs particulares apareçam na saída ou no resultado de alguma consulta. Os servidores de correio interno, por exemplo, não possuem um endereço IP público; portanto, que outro endereço IP eles podem incluir no cabeçalho Received-By que não seja o seu?

Da mesma forma, uma grande rede institucional pode usar redes privadas diferentes entre suas inúmeras LANs. Os pacotes que passam pela rede capturam os IPs privados dos roteadores, mesmo que o pacote retorne à rede pública. Assim, um traceroute pode incluir o IP privado de um roteador em sua saída.

Mito 3: Como os endereços de rede privada não são roteáveis, duas LANs que compartilham o mesmo espaço de endereço de rede privada podem ser conectadas por meio de uma ponte (como uma VPN) sem problemas.

Não vai funcionar - pelo menos não na minha experiência. Digamos que seu trabalho use a rede 192.168.1.x e você use a mesma em casa (como é típico dos roteadores de consumo). Você estabelece uma conexão VPN do seu PC doméstico para o trabalho. Em algum momento, você deseja enviar um trabalho de impressão para uma impressora no trabalho cujo endereço IP é 192.168.1.10. O seu PC doméstico procura na tabela de roteamento para descobrir para onde enviar esse pacote. Que LAN deve recebê-la: sua LAN doméstica ou sua LAN profissional. Resposta: não sei. Talvez este, talvez esse. Um deles conseguirá, mas provavelmente depende do seu sistema operacional e do software VPN para distinguir qual deles tem prioridade. Se for como o software VPN com o qual eu já experimentei, sua LAN doméstica o obterá e, se não houver um dispositivo em 192.168.1.10, o pacote será descartado eventualmente.

Solução: ao usar uma VPN, verifique se as duas LANs estão usando espaços de rede diferentes.

Eu acho que o maior equívoco que vejo é que a rede baseada em IP pode resolver todas as nossas necessidades técnicas ou de TI.

O maior exemplo que vejo disso é o VOIP. É uma infraestrutura de telecomunicações incrivelmente cara, com muitos recursos e difícil de gerenciar adequadamente. Claro que as implantações funcionam ... mais ou menos, mas tenho certeza de que poderia haver sistemas muito melhores com protocolos / infraestrutura dedicados.

Que um ponto de acesso sem fio em estilo doméstico (ou dois) possa substituir uma rede com fio em um ambiente multiusuário. Claro, sua conexão sem fio em casa suporta até 5 PCs, mas você tenta lidar com duas salas de aula de 30 crianças, todas tentando usar laptops para fazer logon em um domínio do Windows ao mesmo tempo. Você precisa de um sistema sem fio gerenciado ou de alguns pontos com fio fixos para lidar com parte (bem, a maioria) da carga. E uma observação rápida para os vendedores de sistemas sem fio gerenciados por aí: sim, tenho certeza de que seu sistema tem melhor desempenho que a concorrência, mas não é infinito - há apenas tanta largura de banda que você pode extrair do conjunto limitado de frequências disponível para 802.11 sem fio, você não pode alterar as leis da física!

Isso, se o compartilhamento de arquivos SMB / NetBIOS não funcionar, nada funcionará na rede (incluindo a navegação na WWW) e toda a rede estará inoperante.

Um ex-educador conectado à web que virou administrador de sistemas pensou isso quando eu estava no ensino médio. Não sei se ela desiludiu a noção acima.

Que tal o equívoco de que você pode dividir a largura de banda de um link (em bits / s) por 8 para modelar com precisão quantos bytes serão transportados. Eu sempre utilizo 75% (máximo) de oito décimos da velocidade do link (ou seja, para um link de 10 GBps, utilizo o máximo de 600 MBps).

OK, eis uma coisa que acabei de descobrir que antes me escapara: para cada pacote que você envia parece que a sobrecarga média é de 38 bytes, incluindo o cabeçalho IP e TCP (é claro que esse valor assume que todos os campos no cabeçalho TCP são usados ao máximo, o tamanho do cabeçalho IP é um valor comum, ou seja, sem valores DSCP, etc., etc.), portanto, para transferir, digamos, 2 MB (com tamanhos de pacote de 64 KB aumentando seus pacotes por segundo [pacotes maiores por segundo = sobrecarga menor] ) você está procurando 1,2 KB de sobrecarga, não muito, mas isso equivale a 6,78 MB para cada 10 GB transferidos e 607,8 MB para cada 1 TB transferido.

Eu me sinto melhor agora: D

Mito: Adicionar mais largura de banda a uma conexão sempre tornará as coisas mais rápidas.

Não muito. Se o seu link não estiver saturado e você estiver tentando obter dados da China para os EUA, pode estar indo o mais rápido possível. Leva tempo (mesmo na velocidade da luz) para ir dos EUA à China, e tornar o link não será mais rápido se você tiver apenas um único fluxo de dados entre os sites.

Afinal de contas, aprimorando um soquete com a SO_LINGERopção de impedir o TIME_WAITestado do TCP porque " TIME_WAITé, você sabe, então, você sabe, velho e, você sabe, como, nojento ".

Que o seu gerente / chefe, o "SR Network Admin", sabe alguma coisa sobre redes reais. Jr Network Admin.