Hoje não aprenderá como configurar e dirigir uma rede. A razão é simples: a gestão de rede e a configuração são uma questão muito complexa que só pode examinar-se resumidamente em um capítulo único. Se se destinar a tarefa do administrador de rede, há alguns bons livros disponíveis o que ajuda um pouco, mas o único professor autêntico de administração de rede e resolução de problemas é experiência. Mais trabalha com redes, mais aprende. O texto de hoje apresenta um resumo da topologia de rede e a configuração emite e examina os passos básicos na resolução de problemas de sistemas TCP/IP defeituosos. Lembre-se de que isto é um resumo só, destinado para provê-lo do contexto ao processo de administração.
Tradicionalmente, a gestão de rede quer dizer duas tarefas diferentes: monitorização e controle da rede. A monitorização significa olhar o comportamento da rede de assegurar que funciona lisamente e olhando para o potencial troublespots. O controle significa modificar a rede enquanto corre, alterando a configuração em alguma maneira de melhorar a realização ou afetar partes que não funcionam corretamente.
No Dia 1, "Sistemas abertos, Padrões e Protocolos", olhei para os padrões de OIS; OIS dirige redes, também. OIS vai além disso do que somente dois aspectos da administração de rede, contudo, dividindo a gestão de rede em cinco partes definidas dentro do Modelo de referência de Ligação de Sistemas Aberto (OSI-RM). Estas cinco partes chamam-se gestão Específica áreas Funcionais (SMFAs) no padrão. Os cinco aspectos são como se segue:
Os cinco grupos têm alguma sobreposição, especialmente entre a realização e acusam a gestão. Contudo, a divisão das tarefas de gestão de rede pode ajudar a prestar contas de todos os aspectos necessários. Em alguns casos, as grandes organizações dedicaram pessoas de cada grupo. Para muita mais pequena LAN, o papel de tratar todos os problemas normalmente cai a uma pessoa, que raramente se incomoda com se as suas ações são COMPLACENTES POR OIS.
Internet Advisory Board (IAB) desenvolveu ou adotou vários padrões da gestão de rede. Estes projetaram-se, em sua maioria, especificamente para ajustar exigências TCP/IP, embora façam sempre que possível encontram a arquitetura OSI. Um grupo de trabalho de Internet responsável pelos padrões de gestão de rede adotou uma aproximação de duas etapas de prover necessidades atuais e futuras.
O primeiro passo implica o uso de Simple Network Management Protocol (SNMP), que se projetou e se implementou pelo grupo de trabalho. SNMP usa-se atualmente em muitas redes de Internet, e integra-se em muitos produtos comercialmente disponíveis. Como a tecnologia melhorou-se, SNMP desenvolveu-se e tornou-se mais abarcamento.
O segundo passo implica padrões de gestão de rede OSI, chamados Common Management Information Services (CMIS) e Common Management Information Protocol (CMIP), ambos para usar-se em futuras implementações de TCP/IP. O IAB publicou Serviços de informações de gestão Comuns e Protocolo sobre TCP/IP (CMOT) como um padrão de TCP/IP e gestão OSI.
Tanto SNMP como CMOT usam o conceito de gerentes de rede que trocam informação com processos dentro de dispositivos de rede como estações de trabalho, pontes, encaminhadores e multiplexadores. A estação de gestão primária comunica-se com os processos de gestão diferentes, construindo a informação sobre a posição da rede. A arquitetura tanto de SNMP como de CMOT é tal que a informação que se reúne se guarda em uma maneira que permite a outros protocolos lê-lo.
O gerente SNMP trata o software total e comunicações entre os dispositivos usando o protocolo de comunicações SNMP. O software de suporte fornece uma interface de usuário, permitindo a um gerente de rede observar a condição do sistema total e componentes individuais e controlar qualquer dispositivo de rede específico.
Os dispositivos SNMP-dirigidos todos contêm o software de reagente SNMP e um banco de dados chamaram Management Information Base (MIB). Olho para o protocolo SNMP e leiaute MIB depois hoje, mas por agora um resumo rápido deve ajudá-lo a entender como SNMP se usa para a gestão de rede. O MIB tem 126 campos da informação sobre a posição de dispositivo, realização do dispositivo, as suas conexões a dispositivos diferentes e a sua configuração. O gerente SNMP questiona o MIB pelo software de reagente e pode especificar modificações da configuração. A maior parte de gerentes SNMP questionam reagentes em um intervalo regular, como quinze minutos, a menos que não instruído de outra maneira pelo usuário.
O software de reagente SNMP é normalmente bastante pequeno (tipicamente menos de 64 KBS) porque o protocolo SNMP é simples. SNMP projeta-se para ser um protocolo que vota, significando que o gerente emite mensagens ao agente. Para eficiência e tamanho pequeno de programas executáveis, as mensagens de SNMP cercam-se dentro de um datagrama UDP e derrotam-se via IP (embora muitos outros protocolos possam usar-se). Há cinco tipos de mensagem disponíveis em SNMP:
O porto de UDP 161 usa-se para todas as mensagens exceto capturas, que chegam ao porto UDP 162. Os agentes recebem as suas mensagens do gerente pelo porto UDP do agente 161.
Apesar do seu uso comum, SNMP tem algumas desvantagens. O mais importante também poderia ser uma vantagem, dependendo do seu ponto de vista: a confiança em UDP. Como UDP é connectionless, não há confiança inerente ao envio de mensagem. Outro problema consiste em que SNMP fornece só um protocolo transmissor simples, a assim filtração de mensagens não pode executar-se. Isto aumenta a carga do software de recepção. Finalmente, SNMP usa a votação, que consome um montante considerável da largura de banda. As trocas entre SNMP e o seu sucessor mais recente, CMIP, tomarão decisões quanto a um protocolo de gestão mais difícil no futuro.
SNMP permite a gestão por procuração, que significa que um dispositivo com um agente SNMP e MIB pode comunicar-se com outros dispositivos que não têm o software de reagente SNMP cheio. Esta gestão por procuração deixa outros dispositivos controlar-se por uma máquina ligada colocando o MIB do dispositivo na memória do reagente. Por exemplo, uma impressora pode controlar-se pela gestão por procuração de uma estação de trabalho que atua como um agente SNMP, que também dirige o agente por procuração e MIB da impressora.
A gestão por procuração pode ser útil para desfazer-se de alguns dispositivos que são abaixo da carga pesada. Por exemplo, é comum abaixo de SNMP usar a procuração para tratar processos de autenticação, que podem consumir recursos consideráveis, passando esta função a uma máquina menos pesadamente usada. Os sistemas por procuração também podem afetar o processamento que tem de executar-se em uma ponte, por exemplo, tendo uma procuração reformatam a chegada de datagramas, novamente para desfazer-se da ponte daquela tarefa demorada.
Depois de fornecer um resumo rápido, posso olhar agora para SNMP mais detalhadamente. Se se satisfizer com o resumo, pode omitir a seguinte seção, porque a maior parte de usuários nunca têm de saber sobre a maquilagem e leiaute de SNMP e MIB. Se quiser saber o que está acontecendo em uma rede, entretanto, esta informação é inestimável.
Simple Network Management Protocol (SNMP) projetou-se originalmente para fornecer um meio de tratar encaminhadores em uma rede. SNMP, embora parte da família TCP/IP de protocolos, não é dependente de IP. SNMP projetou-se para ser independente do protocolo (portanto pode correr abaixo de IPX de SPX/IPX de Novell tão facilmente, por exemplo), embora a maioria de instalações SNMP use IP em redes TCP/IP.
SNMP não é nem um protocolo mas três protocolos que em conjunto compõem uma família, todos projetados para trabalhar em direção a metas de administração. Os protocolos que compõem a família SNMP e os seus papéis seguem:
Peripherals que têm capacidades SNMP corrida construída um pacote de software de reagente de gestão, carregado como parte de um ciclo de bota ou introduzido no firmware no dispositivo. Estes dispositivos com agentes SNMP chamam-se por vários termos dependendo do vendedor, mas se conhecem como dispositivos SNMP-manejáveis ou SNMP-dirigidos. Os dispositivos SNMP-complacentes também têm o código de SNMP incorporado no seu software ou firmware. Quando SNMP existe em um dispositivo, chama-se um dispositivo dirigido.
Os dispositivos SNMP-dirigidos comunicam-se com o software de servidor SNMP localizado em algum lugar na rede. O dispositivo fala com o servidor de dois modos: votado e interrupção. Um dispositivo votado tem o servidor comunicam-se com o dispositivo, pedindo a sua condição atual ou estatística. A votação muitas vezes faz-se regularmente, com o servidor que se une com todos os dispositivos dirigidos na rede. O problema com a votação consiste em que a informação é não sempre corrente e subidas de tráfego de rede com o número de dispositivos dirigidos e a frequência da votação.
Um sistema SNMP baseado na interrupção tem o dispositivo dirigido enviam mensagens ao servidor quando algumas condições garantem. Estes caminho, o servidor sabe de qualquer problema imediatamente (a menos que o dispositivo caia, em que caso a notificação deve ser de outro dispositivo que tentou unir-se ao dispositivo espatifado). Os dispositivos baseados na interrupção têm os seus próprios problemas. Primário entre os problemas é a necessidade de reunir uma mensagem ao servidor, que pode necessitar muitos ciclos de CPU, todos dos quais se levam da tarefa normal do dispositivo. Isto pode causar gargalos e outros problemas naquele dispositivo. Se a mensagem a enviar-se for grande, como é se contiver muitas estatísticas, a rede pode sofrer uma degradação perceptível enquanto a mensagem se reúne e se transmite.
Se há um fracasso principal em algum lugar na rede, como uma grade de poder provisões de poder diminuem e uninterruptible que dão pontapés em, cada dispositivo SNMP-dirigido poderia tentar enviar dirigido pela interrupção em mensagens ao servidor ao mesmo tempo para informar o problema. Isto pode afundar a rede e resultar na informação incorreta no servidor.
Uma combinação de votação e interrupção muitas vezes usa-se para virar-se todos estes problemas. A combinação chama-se a votação dirigida para a captura, e implica o servidor que vota para a estatística de tempo em tempo ou quando dirigido pelo administrador de sistema. Além disso, cada dispositivo SNMP-dirigido pode gerar uma mensagem de interrupção quando certas condições ocorrem, mas estes tendem a definir-se mais rigorosamente do que em um sistema dirigido pela interrupção puro. Por exemplo, se usa SNMP só de interrupção, um encaminhador poderia informar que a carga aumenta cada 10 por cento. Se usar a votação dirigida para a captura, sabe a carga da votação regular e pode instruir o encaminhador para enviar uma interrupção só quando um aumento significante na carga se experimenta. Depois de receber uma mensagem de interrupção com a votação dirigida para a captura, o servidor pode questionar além disso o dispositivo de mais detalhes, se necessário.
Um pacote de software de servidor SNMP pode comunicar-se com os agentes SNMP e transferir ou solicitar vários tipos da informação. Normalmente, o servidor solicita a estatística do agente, inclusive o número de pacotes tratados, a posição do dispositivo, condições especiais associadas com o tipo de dispositivo (como indicações fora do papel ou perda da conexão de um modulador), e carga de processador.
O servidor também pode enviar instruções ao agente de modificar entradas no seu banco de dados (a Base de informação de gestão). O servidor também pode enviar limiar ou condições abaixo das quais o agente SNMP deve gerar uma mensagem de interrupção ao servidor, tal como quando a carga de CPU consegue 90 por cento.
As comunicações entre o servidor e reagente ocorrem em uma maneira regularmente franca, embora tendam a usar a notação abstrata para conteúdos de mensagem. Por exemplo, o servidor poderia enviar um O que é a sua mensagem de carga atual e receba atrás uma mensagem de 75%. O agente nunca envia dados ao servidor a menos que uma interrupção se gere ou um pedido de pesquisa de opinião pública faz-se. Isto significa que alguns problemas existentes há muito tempo podem existir sem o conhecimento de servidor SNMP sobre eles, simplesmente porque uma pesquisa de opinião pública não se conduziu ou uma interrupção gera-se.
Cada dispositivo SNMP-dirigido mantém um banco de dados que contém a estatística e outros dados. Estes bancos de dados chamam-se uma Base de informação de gestão ou MIB. As entradas MIB têm quatro partes da informação neles: um tipo de objeto, uma sintaxe, um campo de acesso e um campo de posição. As entradas de MIB estandardizam-se normalmente pelos protocolos e seguem regras de formatação estritas definidas pela Notação de Sintaxe Abstrata Uma (ASN.1).
O tipo de objeto é o nome da determinada entrada, normalmente como um nome simples. A sintaxe é o tipo de valor, como uma cadeia ou número inteiro. Não todas as entradas em um MIB têm um valor. O campo de acesso usa-se para definir o nível do acesso à entrada, normalmente definida pelos valores somente de leitura, ler - escrevem, só escrever, e não acessíveis. O campo de posição contém uma indicação de se a entrada no MIB é obrigatória (que significa que o dispositivo dirigido deve implementar a entrada), opcional (o dispositivo dirigido pode implementar a entrada), ou obsoleto (não usado).
Há dois tipos de MIB no uso, chamado MIB-1 e MIB-2. As estruturas são diferentes. MIB-1 usou-se começando em 1988 e tem 114 entradas na mesa, dividida em grupos. Para um dispositivo dirigido para afirmar ser MIB-1 compatível, deve tratar todos os grupos que são aplicáveis a ele. Por exemplo, uma impressora dirigida não tem de implementar todas as entradas que tratam com Exterior Gateway Protocol (EGP), que só se implementa normalmente por encaminhadores e dispositivos semelhantes.
MIB-2 é um aumento de 1990 de MIB-1, composto de 171 entradas em dez grupos. As adições estendem-se sobre algumas entradas de grupo básicas em MIB-1 e acrescentam três novos grupos. Como com MIB-1, um dispositivo SNMP que afirma ser MIB-2 complacente deve implementar todos aqueles grupos que são aplicáveis àquele tipo do dispositivo. Encontrará muitos dispositivos que são MIB-1 complacente mas não MIB-2.
Além de MIB-1 e MIB-2, vários MIBs experimentais no uso acrescentam grupos diferentes e entradas no banco de dados. Nenhum destes se adotou largamente, embora alguma promessa de demonstração. Alguns MIBs também se desenvolveram por corporações individuais do seu próprio uso, e alguns vendedores oferecem a compatibilidade com estes MIBs. Por exemplo, Hewlett-Packard desenvolveu um MIB do seu próprio uso que alguns dispositivos SNMP-dirigidos e os pacotes de servidor de software apoiam.
Simple Network Management Protocol (SNMP) foi por meio de várias iterações. A versão o mais comumente usada chama-se SNMP v1. Normalmente SNMP usa-se como uma aplicação de cliente/servidor assíncrona, significando que o dispositivo dirigido ou o software de servidor SNMP podem gerar uma mensagem ao outro e esperar por uma resposta, se esperarem um. Estes empacotam-se e tratam-se pelo software de rede (como IP) como qualquer outro pacote seria. SNMP usa UDP como um protocolo de transportação de mensagem. O porto de UDP 161 usa-se para todas as mensagens exceto capturas, que chegam ao porto UDP 162. Os agentes recebem as suas mensagens do gerente pelo porto UDP do agente 161.
Quando um pedido se envia, deixam alguns campos na entrada SNMP espaço em branco. Estes preenchem-se pelo cliente e devolvem-se. Isto é um método eficiente de transferir a pergunta e resposta em um bloco, eliminando algoritmos de busca complexos para descobrir o que questiona uma resposta recebida aplica.
A ordem adquirir, por exemplo, envia-se com os campos de Valor e Tipo no jogo de mensagem ao NULO. O cliente retorna uma mensagem semelhante com estes dois campos preenchidos (a menos que não se apliquem, em que caso uma mensagem de erro diferente se devolve).
SNMP v2 acrescenta algumas novas capacidades à mais velha versão SNMP, a mais prática das quais para servidores é a operação de adquirir-volume. Isto deixa um grande número de entradas MIB enviar-se em uma mensagem, em vez de necessitar múltiplas perguntas de vir depois com SNMP v1. Além disso, SNMP v2 tem a segurança muito melhor do que SNMP v1, impedindo intrusos não desejados de controlar o estado ou a condição de dispositivos dirigidos. Tanto a encriptação como a autenticação apoiam-se por SNMP v2. SNMP v2 é um protocolo mais complexo e não se usa tão largamente como SNMP v1.
Apesar do seu uso comum, SNMP tem algumas desvantagens. O mais importante é a sua confiança em UDP. Como UDP é connectionless, não há confiança inerente à transmissão de mensagens entre servidor e reagente. Outro problema consiste em que SNMP fornece só um protocolo transmissor simples, a assim filtração de mensagens não pode executar-se. Isto aumenta a carga do software de recepção. Finalmente, SNMP quase sempre usa a votação até certo ponto, que consome um montante considerável da largura de banda.
Embora muitos sistemas operacionais apoiem SNMP e lhe permitam configure o seu uso, SNMP permanece um protocolo muito UNIX-orientado. As possibilidades são, se houver uma caixa UNIX na sua rede, SNMP é baseado na máquina UNIX. Outros sistemas operacionais como suporte de Windows NT cliente de SNMP e software de servidor — e são normalmente muito fáceis estabelecer-se e arranjar-se — mas para esta seção me curvo à maioria e só olho para UNIX.
A maior parte de versões UNIX incluem tanto o cliente como software de servidor como parte do sistema operacional. O software de cliente realiza-se pelo demônio snmpd, que normalmente corre todo o tempo quando SNMP se usa na rede. Normalmente, o demônio snmpd começa-se automaticamente quando as botas de sistema; controla-se pelos arquivos de lançamento rc. Quando SNMP começa, o demônio lê vários arquivos de configuração. Na maior parte de agentes SNMP, os arquivos que snmpd lê são como se segue:
/etc/inet/snmpd.conf
/etc/inet/snmpd.comm
/etc/inet/snmpd.trap
Os diretórios abaixo dos quais estes arquivos são poderiam ser diferentes para cada versão UNIX, portanto deve verificar o sistema de arquivos a sua posição própria.
O arquivo snmpd.conf contém quatro sistema objetos de MIB. A maior parte do tempo estes objetos estabelecem-se durante a instalação, mas poderia querer verificar os seus conteúdos. Uma amostra snmpd.conf arquivo mostra-se aqui:
# @(#)snmpd.conf 6.3 8/21/93 - STREAMware TCP/IP source # # Copyrighted as an unpublished work. # Copyright 1987-1993 Lachman Technology, Inc. # All rights reserved. descr=SCO TCP/IP Runtime Release 2.0.0 objid=SCO.1.2.0.0 contact=Tim Parker tparker@tpci.com location=TPCI Int'l HQ, Ottawa
Em muitos arquivos snmpd.conf tem de preencher o contato e campos de posição você mesmo (que definem o usuário de contato e posição física do sistema), mas o descr e os campos objid devem deixar-se como são. As variáveis definidas no arquivo snmpd.conf correspondem a variáveis MIB como mostrado na Tabela 13.1.
|
Variáveis de snmpd.comf |
Variáveis de MIB |
|
descr |
sysDescr |
|
objid |
sysObjectID |
|
contatos |
sysContact |
|
posição |
sysLocation |
O snmpd.comm (comunidade) o arquivo usa-se para fornecer a informação sobre autenticação e uma lista de anfitriões que têm o acesso ao banco de dados local. O acesso por uma máquina remota aos dados SNMP locais fornece-se pela inclusão do nome da máquina remota no arquivo snmpd.comm. Uma amostra snmpd.comm arquivo parece a isto:
# @(#)snmpd.comm 6.5 9/9/93 - STREAMware TCP/IP source accnting 0.0.0.0 READ r_n_d 147.120.0.1 WRITE public 0.0.0.0 READ interop 0.0.0.0 READ
Cada linha no arquivo snmpd.comm tem três campos: o nome de comunidade, o endereço IP da máquina remota e os privilégios a comunidade têm. Se o endereço IP se estabelecer em 0.0.0.0, qualquer máquina pode comunicar-se com aquele nome de comunidade. Os privilégios podem LER-SE para o somente de leitura, ESCREVER para o lido e escrever, e NENHUM para prevenir o acesso por aquela comunidade. Leia e escreva que o acesso é referências para capacidades de modificar dados MIB, não sistemas de arquivos.
O arquivo snmpd.trap especifica o nome de anfitriões que uma mensagem de captura deve enviar-se quando um evento crítico se nota. Uma amostra snmpd.trap arquivo parece a isto:
# @(#)snmpd.trap 6.4 9/9/93 - STREAMware TCP/IP source superduck 147.120.0.23 162
Cada linha no arquivo snmpd.trap tem três campos: o nome da comunidade, o seu endereço IP e o porto UDP para usar para enviar capturas.
UNIX oferece várias ordens baseadas em SNMP de administradores de rede de obter a informação de um MIB ou um dispositivo SNMP-complacente. As ordens exatas variam um pouco dependendo da implementação, mas a maior parte de sistemas SNMP apoiam as ordens mostradas na Tabela 13.2.
|
Ordem |
Descrição |
|
getone |
Usos o SNMP adquirem a ordem de recuperar um valor variável |
|
getnext |
Usa o SNMP getnext ordem de recuperar o seguinte valor variável |
|
getid |
Recupera os valores de sysDescr, sysObjectID, e sysUpTime |
|
getmany |
Recupera um grupo inteiro de variáveis MIB |
|
snmpstat |
Recupera os conteúdos de estruturas de dados SNMP |
|
getroute |
Recupera a informação sobre encaminhamento |
|
setany |
Usa a ordem de jogo de SNMP de estabelecer um valor variável |
A maioria das ordens de SNMP necessitam um argumento que especifica a informação a estabelecer-se ou recuperar-se. A produção de algumas ordens dadas na Tabela 13.2 mostra-se no seguinte extrato de uma máquina SNMP em uma pequena rede local:
$ getone merlin udpInDatagrams.0 Name: udpInDatagrams.0 Value: 6 $ getid merlin public Name: sysDescr.0 Value: UNIX System V Release 4.3 Name: sysObjectID.0 Value: Lachman.1.4.1 Name: sysUpTime.0 Value: 62521
Nenhuma das ordens de SNMP pode chamar-se fácil de usar, porque as suas respostas são concisas e às vezes difíceis de analisar. Por essa razão, muitos rede baseada em GUI analisadores ficam populares, oferecendo o acesso baseado no cardápio a muitas funções de SNMP e melhor apresentação de dados. O uso de um instrumento SNMP baseado em GUI pode apresentar exposições gráficas coloridas da estatística de rede em uma maneira em tempo real. Contudo, estes instrumentos GUI tendem a custar um montante considerável.
Resumidamente examinei tanto a LAN como a topologia PÁLIDA no Dia 1, olhando para ônibus e redes anulares e as conexões entre a LAN para fazer um PÁLIDO, para que o material deva ser um tanto familiar para você. Pode estender agora a sua atenção da topologia de LAN à topologia interem rede maior usando TCP/IP. Para fazer isto, devo atar o papel de encaminhadores, pontes e dispositivos semelhantes na topologia de rede e mostrar o seu papel em um sistema TCP/IP.
Um conceito útil para ter em mente é a regra de 80/20, que afirma que 80 por cento da maior parte de tráfego de rede são para máquinas locais, e 20 por cento têm de partir a LAN. Na verdade, a proporção do tráfego local é normalmente muito mais alta, mas planejando quanto a uma divisão de 80/20 ajuda a estabelecer limites trabalháveis de conexões a espinhas dorsais de rede.
A LAN ata-se a uma espinha dorsal de rede maior (um PÁLIDO ou umas interredes como a Internet) por um dispositivo que trata a passagem de datagramas entre a LAN e a espinha dorsal. Em uma organização simples, um encaminhador executa esta função. Isto mostra-se na Figura 13.1. Os encaminhadores unem redes que usam protocolos de camada de conexão diferentes ou protocolos de Media Access Control (MAC). Os encaminhadores só examinam as cabeçadas de datagramas que se enviam especificamente eles ou são mensagens de transmissão, mas há muito de processar implicado dentro do encaminhador.
A figura 13.1. Um encaminhador une uma LAN à espinha dorsal.
Se duas ou mais LAN se implicar em uma organização e há possibilidade de muito tráfego entre eles, é melhor unir a duas LAN diretamente com uma ponte em vez de carregar a espinha dorsal com o transversal tráfego. Isto mostra-se na Figura 13.2. As pontes também podem unir dois WANs utilização de uma linha de alta velocidade, como mostrado na Figura 13.3.
A figura 13.2. Usar uma ponte para unir duas LAN.
A figura 13.3. Usar uma ponte para unir dois WANs.
Poderia lembrar que as pontes se usam quando o mesmo protocolo de rede está em amba a LAN, embora a ponte não se preocupe que meios de comunicação físicos se usa. As pontes podem unir a LAN de par torcido à LAN coaxial, por exemplo, ou atuar como uma interface para uma fibra a rede ótica. Enquanto o protocolo de Media Access Control (MAC) é o mesmo, a ponte funciona propriamente.
Muitas pontes de alta qualidade disponíveis hoje configuram-se automaticamente às redes unem e aprendem os endereços físicos do equipamento em cada LAN controlando o tráfego. Um problema com pontes consiste em que examinam cada datagrama que passa por eles, verificando a fonte e endereços de destino. Isto acrescenta em cima e reduz a velocidade do encaminhamento pela ponte. (Como mencionado antes, os encaminhadores não examinam cada datagrama.)
Em uma configuração usando pontes entre a LAN ou WANs, o tráfego de uma LAN ao outro pode enviar-se pela ponte em vez de para a espinha dorsal, fornecendo a melhor realização. Para serviços como Telnet e FTP, a diferença de velocidade entre utilização de uma ponte e passagem de um encaminhador para uma espinha dorsal pesadamente usada pode ser apreciável. Se a espinha dorsal não for sob a administração direta dos administradores da LAN (como com a Internet), ter uma ponte também fornece um método para a corporação ou organização para controlar a conexão.
O uso de uma ponte tem uma outra vantagem: se a espinha dorsal falhar, as comunicações entre a duas LAN não se perdem. O mesmo aplica-se, naturalmente, se a ponte falhar, porque a espinha dorsal pode usar-se como um caminho de desvio. Para redes críticas, as espinhas dorsais duplicam-se normalmente para a redundância. Na mesma maneira, a maior parte de organizações têm encaminhadores duplicados e pontes em caso do fracasso.
As pontes podem usar-se partindo uma grande LAN em mais pequenas redes. Isto muitas vezes é necessário quando uma LAN continua expandindo-se como se acrescenta o novo equipamento. Consequentemente o tráfego de rede torna-se bottlenecked. Uma solução útil e relativamente fácil é dividir a LAN maior na mais pequena LAN unida sobre uma espinha dorsal. Isto ajuda a conformar-se com a regra de 80/20, simplificando o tráfego e administração em cima. Isto mostra-se na Figura 13.4. Se a espinha dorsal se escolher cuidadosamente com muita capacidade excessiva, este tipo da topologia pode prestar contas do futuro crescimento relativamente grande.
A figura 13.4. Dividir uma grande LAN em vária mais pequena LAN.
Os encaminhadores, também, podem usar-se para controlar grandes redes. Isto é uma vantagem quando as transmissões se usam frequentemente, porque o encaminhador pode filtrar transmissões que só se aplicam a uma LAN específica. (A maior parte de pontes propagam transmissões através da rede.) O uso de um encaminhador de comutação único ou encaminhador de cubo da roda fica popular para juntar a LAN diferente dentro de uma organização, tão mostrada como na Figura 13.5.
A figura 13.5. Usar um encaminhador de cubo da roda para unir a LAN.
Quando as grandes redes são necessárias, vários encaminhadores podem usar-se para partir a carga. Os encaminhadores de rede inteligentes podem otimizar o encaminhamento de datagramas, bem como controlar e controlar tráfego de rede e gargalos em qualquer posição.
Em muitas ocasiões as vantagens de uma ponte e um encaminhador em conjunto são ideais. Estes dispositivos combinados, chamados brouters, fazem agora uma aparência. Brouters pode executar o encaminhamento com algumas mensagens e lançando uma ponte com outros examinando datagramas de entrada e usando uma máscara de filtro para decidir que função se executa. Brouters têm a capacidade de tratar múltiplos protocolos, muito como encaminhadores.
O equipamento disponível hoje é muito mais capaz do que esteve disponível quando TCP/IP começou o seu ciclo de desenvolvimento. De alguns modos, isto simplificou a tarefa de soma a ou configuração de uma rede, mas também pôs alguns problemas do seu próprio. A maior parte de equipamento pode acrescentar-se a uma rede anexando simplesmente o meio de rede (como um fio coaxial ou fio de par torcido) e configurando a interface com o endereço IP e nome de domínio.
Naturalmente, mais complicado a rede, mais trabalho deve fazer-se. Configurar uma ponte, por exemplo, pode ser tão simples como união dele às redes que serve. A maior parte de pontes podem autoconfigurar-se e olhar o tráfego de rede para construir uma mesa do endereço de rede. Contudo, acrescentar filtros para restringir o tráfego ou limitar acesso por meio do bloqueio de portos necessitam processos de configuração mais detalhados.
Configurar uma rede e TCP/IP não é difícil, mas pode ser demorado. Os sistemas operacionais diferentes aproximam a tarefa de vários modos. UNIX, por exemplo, usa um grande número de pequenos arquivos de configuração espalhados em todas as partes do sistema de arquivos. Os computadores centrais de IBM usam um grande arquivo único. As configurações em alguns sistemas usam uma interface dirigida pelo cardápio que guia o usuário por todos os passos necessários, assegurando que nenhum erro se faz.
Para a maior parte de redes e os seus cartões de interface, a seguinte informação necessita-se:
Os endereços IP secundários podem usar-se para dispositivos como encaminhadores, que podem tratar duas redes lógicas. Como observado, as interfaces seriais não precisam de um endereço IP, embora possam fornecer-se. As interfaces seriais também necessitam que uma colocação indique se o dispositivo se configura para atuar como Data Terminal Equipment (DTE) ou Data Communications Equipment (DCE), a tarifa de baud do porto serial e paridade e colocações do tamanho máximo de uma transmissão.
Tudo o que o equipamento usa-se em uma rede, todos eles têm uma conexão física ao meio de transporte de rede. Tipicamente isto é uma placa de rede em uma estação de trabalho, PC de mesa ou impressora. O software fornecido com o dispositivo controla a interface, eliminando a maioria das preocupações de combinar com hardware, software e protocolos. Depois de decidir um endereço IP, a colocação pode programar-se por comutadores ou por software, e o dispositivo está pronto para falar com a rede.
Os endereços IP podem escolher-se a esmo pelo administrador de sistema, mas isto pode causar problemas quando os datagramas se lançam a umas interredes maiores como a Internet. De maneira ideal, uma máscara de rede destina-se por Network Information Center (NIC). Isto então combina-se com o próprio esquema de numeração do administrador na LAN para produzir o endereço IP cheio.
Os endereços IP destinam-se pelo baseado NIC na classe da rede, que reflete o tamanho da organização e o número de endereços de equipamento locais necessitados. Como mostrado na Figura 13.6, há quatro estruturas de endereço IP NIC-aprovadas. Classe que Uns endereços são para redes muito grandes que precisam de 24 bits disponíveis para endereços locais, reduzindo o endereço de rede a 7 bits. A classe B destina 16 bits localmente e 14 bits do endereço de rede, ao passo que a Classe C permite só 8 bits de endereços locais e 21 bits do endereço de rede. As redes da classe C são para pequenas empresas só, porque podem criar-se só 256 endereços locais. Os endereços da classe D usam-se para sistemas especiais não normalmente encontrados por usuários.
A figura 13.6. As quatro estruturas de classe de endereço IP.
Os esquemas numeram dentro de uma rede deixam-se ao capricho do administrador, embora uma convenção de destinar números baixos a encaminhadores e pontes se siga normalmente. Também é útil usar Address Resolution Protocol (ARP) em servidores locais ou encaminhadores para prover o lançamento mais rápido quando as máquinas questionam para os seus endereços IP. Isto previne transmissões por todo o sistema. A maneira na qual o equipamento de usuário lança (se usa BOOTP, ARP ou RARP) pode afetar a configuração dos servidores locais e encaminhadores.
Os endereços físicos de conectores de rede raramente têm de modificar-se das suas colocações à revelia. A maior parte de vendedores garantem uma colocação física única do seu hardware, portanto estes podem manter-se normalmente sem modificação. Para a conversão do endereço IP ao endereço físico, esta informação deve guardar-se em uma tabela de roteamento.
As tabelas de roteamento de pequenas redes muitas vezes criam-se e mantêm-se à mão. As redes maiores poderiam implicar demasiadas modificações da aproximação manual de ser eficazes, portanto um protocolo de encaminhamento como Routing Information Protocol (RIP) se usa. Vários protocolos de encaminhamento estão disponíveis, inclusive o RASGÃO e Open Shortest Path First (OSPF). A escolha do protocolo de encaminhamento pode ser importante e normalmente depende do tamanho da rede e as conexões entre subredes e sistemas externos. Os protocolos de encaminhamento devem começar-se automaticamente quando a rede se inicializa.
A configuração a rede inclui a colocação do nome de domínio e rede máscara de IP, depois dos formatos aprovados pelo NIC. Muitos sistemas operacionais têm a utilidade que a ajuda configura o nome de domínio e rede máscara de IP. O Guia de Administrador de Domínio, que descreve o processo de formar um nome de domínio, está disponível do NIC (RFC 1032). Estes passos só aplicam-se se a rede dever unir-se à Internet ou umas interredes semelhantes. Se a rede for autônoma sem conexões exteriores, o administrador pode escolher qualquer rede máscara de IP e nome de domínio (embora as futuras conexões pudessem forçar uma reconfiguração completa da rede se um esquema NIC-consistente não se usa).
As conexões à Internet necessitam um número de Autonomous System (AS) do NIC, que provê outros sistemas do seu endereço de encaminhador de borda. Os protocolos de portão como Exterior Gateway Protocol (EGP) ou mais novo Border Gateway Protocol (BGP) devem instalar-se e configurar-se para fornecer o encaminhamento de Internet.
Também implicado na nomeação são as mesas de resolução de nome para o endereço, que convertem um nome simbólico para um endereço IP. Estes configuram-se normalmente manualmente, embora alguns formatação automatizada de instrumentos se ofereçam com sistemas operacionais diferentes. Se Domain Name System (DNS) dever implementar-se, que acrescenta outro nível da complexidade à configuração de nome, os detalhes da qual se deixam melhor a textos mais especializados.
Alguns encaminhadores podem configurar-se para filtrar o tráfego de mensagem. Nestes casos, as máscaras costumaram restringir ou permitir datagramas deve acrescentar-se às mesas de encaminhador, bem como qualquer limitação ou exceções a pedidos em serviços de tomada (como Telnet). Estabelecer mesas de ARP em encaminhadores pode ajudar a subir máquinas recentemente começadas mais rapidamente que se uma transmissão se enviar por toda a rede ao servidor ARP primário. Vários encaminhadores podem configurar-se para o encaminhamento de prioridade, permitindo a prioridade baseada no protocolo, tipo do serviço ou uns critérios selecionados como endereço IP ou tomada.
O software Router pode acessar-se localmente por um terminal dedicado ou sobre a rede. O último permite a um administrador de sistema logar usando Telnet de uma máquina na rede e logo dirigir a utilidade de manutenção ou a configuração. É aconselhável fazer o acesso a esta utilidade extremamente limitado.
Depois que os endereços de rede estabeleceram-se, TCP pode configurar-se. Isto executa-se normalmente em uma base por máquina usando uma utilidade de interface. Em TCP configuração de software são colocações de tamanhos de janela à revelia e tamanho de segmento máximo. Se se transformar as nomeações de porto de TCP padrão necessitam-se, os arquivos de configuração devem editar-se. Os processos que começam TCP e controlam portos de conexões (como inetd, descrito no Dia 6, "Telnet e FTP") deve acrescentar-se aos arquivos de lançamento de sistema. Outros serviços como correio eletrônico (que poderia usar um protocolo dedicado como SNMP) devem instalar-se e propriamente configurar-se.
Em Dias 6 e 7 olhei para a utilidade de rede TCP/IP como silvo, dedo, ruptime, e netstat, que ajuda determinam a posição de conexões e interfaces. Menciono-os aqui novamente resumidamente e também introduzo algumas novas ordens. Vários vendedores de software agora oferecem produtos de monitorização de rede talentosos que fornecem a informação excelente sobre a rede, as suas conexões e o tráfego que transporta. Muitos destes produtos também permitem a configuração dinâmica do sistema.
O silvo (Internet de Pacote Groper) ordem é o método mais fácil para verificar a conexão de uma máquina à rede. Usa Internet Control Message Protocol (ICMP) para enviar um pedido na resposta. A ordem de silvo é útil com encaminhadores, porque pode verificar cada interface. As versões diferentes do silvo estão disponíveis, alguns com opções diferentes.
A seguinte produção mostra um sistema baseado no caráter usando o silvo para verificar outra máquina na rede. A linha de comando usa a opção-c de limitar o número de pacotes enviados. Como pode ver, um endereço IP usou-se para indicar a máquina de destino, e a máquina traduziu isto ao pimentão de nome simbólico baseado na mesa de anfitrião.
# ping -c5 205.150.89.2 PING 205.150.89.2 (205.150.89.2): 56 data bytes 64 bytes from pepper (205.150.89.2): icmp_seq=0 ttl=32 time=40 ms 64 bytes from pepper (205.150.89.2): icmp_seq=1 ttl=32 time=0 ms 64 bytes from pepper (205.150.89.2): icmp_seq=2 ttl=32 time=0 ms 64 bytes from pepper (205.150.89.2): icmp_seq=3 ttl=32 time=0 ms 64 bytes from pepper (205.150.89.2): icmp_seq=4 ttl=32 time=0 ms --- 205.150.89.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0/8/40 ms
Uma utilidade de silvo baseada em GUI mostra-se na Figura 13.7. Isto mostra a utilidade de silvo de ChameleonNFS enviando um pacote único a um dispositivo remoto (neste caso uma impressora de rede com o endereço IP 205.150.89.200) e adquirindo uma resposta positiva.
A figura 13.7. o silvo também pode usar-se em sistemas GUI, embora normalmente com menos opções do que em UNIX.
Uma utilidade semelhante é borrifo, que usa uma Chamada de procedimento remoto (RPC, discutido no Dia 9, "Fundando uma Rede de TCP/IP de Mostra: Servidores") para enviar uma corrente constante de datagramas ou mensagens ICMP. A diferença entre silvo e borrifo é que o borrifo envia os datagramas constantemente, ao passo que o silvo tem um intervalo entre datagramas. Isto pode ser útil para verificar capacidades de modo do estouro da rede. A produção de uma ordem de borrifo em um BSD UNIX sistema parece a isto:
$ spray -c 5 tpci_sun2 sending 5 packets of lnth 86 to tpci_sun2 ... in 0.3 seconds elapsed time, 1 packets (20.00%) dropped by tpci_sun2 Sent: 19 packets/sec, 1.8K bytes/sec Rcvd: 16 packets/sec, 1.6K bytes/sec
Dia 7, "a Configuração TCP/IP e a administração Fundamentos", cobriu a ordem de netstat em algum detalhe. É útil para verificar a posição da rede. As implementações de netstat variam largamente dependendo da versão de sistema operacional.
Alguns sistemas têm traceroute chamado de uma utilidade (disponível como software de domínio público), que envia uma série de datagramas UDP ao objetivo. Os datagramas constroem-se ligeiramente diferentemente dependendo da sua posição na corrente. Três primeiros datagramas têm o jogo de campo de Tempo para viver (TTL) a 1, significando a primeira vez quando um encaminhador encontra a mensagem devolve-se com uma mensagem vencida. Três seguintes mensagens têm o jogo de campanha TTL a 2, e assim por diante até que o destino se consiga.
A produção traceroute mostra o tempo de viagem de ida e volta de cada mensagem (que é útil para identificar gargalos na rede) e a eficiência dos algoritmos de encaminhamento (por um número de encaminhadores que não poderiam ser a melhor via). Uma produção de mostra de uma ordem de traceroute (todos os nomes de máquina e o endereço IP se inventam) segue:
$ traceroute black.cat.com 1 TPCI.COM (127.01.13.12) 51ms 3ms 4ms 2 BEAST.COM (143.23.1.23) 60ms 5ms 7ms 3 bills_machine.com (121.22.56.1) 121ms 12ms 12ms 4 SuperGateway.com (130.12.14.2) 75ms 13ms 10ms 5 black.cat.com (122.13.2.12) 45ms 4ms 6ms
Tratando com RPC, uma utilidade chamou rpcinfo pode determinar que serviços RPC são atualmente ativos no habitante local ou qualquer sistema remoto que apoia RPC. As opções apoiadas por rpcinfo variam com a implementação, mas todos permitem a bandeiras decidir que o tipo do serviço verificar. Por exemplo, a opção-p expõe o portmapper local. O seguinte exemplo mostra as opções apoiadas no SCO UNIX a versão de rpcinfo, bem como a produção do portmapper:
$ rpcinfo
Usage: rpcinfo [ -n portnum ] -u host prognum [ versnum ]
rpcinfo [ -n portnum ] -t host prognum [ versnum ]
rpcinfo -p [ host ]
rpcinfo -b prognum versnum
$ rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
150001 1 udp 1026 pcnfsd
150001 2 udp 1026 pcnfsd
100008 1 udp 1027 walld
100002 1 udp 1028 rusersd
100002 2 udp 1028 rusersd
100024 1 udp 1029 status
100024 1 tcp 1024 status
100020 1 udp 1034 llockmgr
100020 1 tcp 1025 llockmgr
100021 2 tcp 1026 nlockmgr
100021 1 tcp 1027 nlockmgr
100021 1 udp 1038 nlockmgr
100021 3 tcp 1028 nlockmgr
100021 3 udp 1039 nlockmgr
Controlar NFS (um serviço RPC) pode ser mais complicado. Alguns programas de serviço estão disponíveis. Os nfsstat ordenam a informação sobre exposições sobre chamadas recentes:
$ nfsstat Server rpc: calls badcalls nullrecv badlen xdrcall 458 0 1 2 0 Server nfs: calls badcalls 412 2 null getattr setattr root lookup readlink read 0 0% 200 49% 0 0% 0 0% 120 29% 75 18% 126 31% wrcache write create remove rename link symlink 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% mkdir rmdir readdir fsstat 0 0% 0 0% 52 13% 12 3% Client rpc: calls badcalls retrans badxid timeout wait newcred 1206 1 0 0 3 0 0 peekeers badresps 0 1 Client nfs: calls badcalls nclget nclsleep 1231 0 1231 0 null getattr setattr root lookup readlink read 0 0% 0 0% 0 0% 0 0% 562 46% 134 11% 137 11% wrcache write create remove rename link symlink 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% mkdir rmdir readdir fsstat 0 0% 0 0% 239 19% 98 8%
As demonstrações de programa de monte que diretórios se montam atualmente, e a ordem showmount mostram os servidores de NFS atuais no sistema:
$ mount pepper:/ /server nfs ro,bg,intr pepper:/apps /server/apps nfs ro,bg,intr pepper:/usr /server/usr nfs rw,bg,intr pepper:/u1 /server/u1 nfs rw,bg,intr $ showmount m_server.tpci.com merlin.tpci.com sco_gate.tpci.com tpti.tpci.com
A produção de monte mostra os diretórios na máquina denominada pimentão que se montaram para o diretório de servidor / local quando o sistema inicializou. As permissões de cada diretório montado mostram-se no fim de cada linha, onde ro significa somente de leitura e os meios de rw lidos - escrevem. O bg nas linhas de posição significa o contexto, indicando isto se o monte falhar, as tentativas de sistema novamente periodicamente. A opção enterrar significa que as interrupções de teclado podem usar-se para parar as tentativas de reconexão.
Também disponível como software de domínio público são nfswatch e nhfsstone. A utilidade nfswatch controla todo o tráfego de NFS em um servidor e atualiza a informação sobre posição em intervalos predeterminados. Isto pode ser útil para olhar a carga modificar-se durante o dia. A utilidade nhfsstone é para teste de desempenho de um sistema, geração de uma carga artificial e medir dos resultados.
Um método rápido para verificar o funcionamento apropriado de um porto deve unir-se a ele com Telnet ou FTP. Ambos os programas permitem ao usuário especificar o porto para usar em vez do default. No seguinte exemplo, o porto 25 (normalmente usado para o correio) testa-se:
$ telnet tpci_hpws4 25 Trying 127.12.12.126 ... Connected to tpci_hpws4. Escape shcracter is '^]'. 220 tpci_hpws4 Sendmail 3.1 ready at Sat, 2 July 94 12:16:54 EST HELO TPCI_SERVER_1 250 tpci_hpws4 This is garbage typed to force a closed connections as it doesn't understand this stuff QUIT 221 tpci_hpws4 closing connection Connection closed by foreign host.
Neste exemplo, o porto 25 recebeu o pedido de conexão propriamente e esperou pelas mensagens de protocolo de correio. Como não adquiriu nenhum, fechou a conexão. Esta sessão curta estabelece aquele porto 25 funciona propriamente pelo que as conexões estejam em questão. Não transmite nenhuma informação sobre a integridade do protocolo de transferência de correio, entretanto.
Toda desta utilidade pode combinar-se para fornecer uma lista de conferência de resolução de problemas para problemas básicos. Estes dizem-lhe pelo menos onde o problema é, se não mais. Um procedimento diagnóstico reúne-se da utilidade, como o seguinte:
Naturalmente, se os melhores instrumentos estão disponíveis de fontes comerciais, use-os à sua vantagem cheia. É importante saber que não tem de passar milhares de dólares em um instrumento de monitorização de rede, porque a utilidade fornecida com o sistema operacional muitas vezes é bastante capaz (se não como imaginação ou graficamente orientado).
A conexão física à rede é um ponto de partida conveniente para investigar quando um problema não é óbvio. Como há muitos interfaces de rede populares, cada um dos quais deve tratar-se em uma maneira ligeiramente diferente, algumas generalizações devem fazer-se. A aproximação total permanece o mesmo, de qualquer modo.
Supondo que a própria rede seja funcional, a maior parte de problemas comuns com o interface de rede são uma placa de rede defeituosa ou um mau conector. A verificação de cada um faz-se facilmente pela substituição simples. Se o problema persistir, a falta é mais provavelmente mais alta na arquitetura.
Os meios de comunicação de transporte de rede defeituosos (normalmente fios) são bastante comuns. Se um dispositivo no fim de um fio não estiver funcionando, é de mérito verificar o próprio fio para assegurar que um caminho de comunicação existe. Isto pode fazer-se com um computador portátil ou terminal, ou em alguns casos um provador de condutividade, dependendo da rede. Um processo de prova sistemático pode reduzir um problema de telegrafar de rede a um segmento específico.
Um problema contemplado do alto surge não devido a uma verdadeira falta com o interface de rede ou a própria rede, mas porque um dispositivo na rede transmite um protocolo diferente. Isto pode sujar a rede inteira e moê-la a uma parada. (Por exemplo, uma rede de Ethernet poderia ter um ou vários dispositivos jogo para transmitir armações de IEEE 802.3, que não são o mesmo como Ethernet.)
Se houver uma conversão de um protocolo ao outro, que pode ser suspeito. Por exemplo, é comum encontrar redes de AppleTalk que dirigem TCP/IP. As mensagens IP encapsulam-se em armações de AppleTalk. Se a conversão entre os dois formatos (que pode ocorrer em um portão ou encaminhador) não é limpa, alguns pacotes defeituosos poderiam passar-se. Isto pode causar problemas de rede.
Se as conexões de rede e os cartões de interface de rede parecerem estar trabalhando (que pode verificar-se com uma rede analisador ou troca de conselho), o problema está em uma camada mais alta.
UMA CARTEIRA DE IDENTIDADE = NOME "DE E69E175" = "E69E175">
A camada de rede (onde IP reside) pode ser o aspecto mais propenso à preocupação da rede se as regras de configuração não se seguirem escrupulosamente. Como esta camada trata o encaminhamento, qualquer erro pode causar pacotes perdidos, fazendo-o aparecer que uma máquina na rede não se comunica com os outros. ICMP pode ser um instrumento útil para investigar esta camada.
Um da maior parte de erros comuns, especialmente com grandes redes, é uma duplicação de endereços IP. Isto pode ser um acidente, como um novo endereço se programa, ou um usuário pode mover a sua máquina e no processo misturam o endereço IP. É bastante comum para usuários modificar o endereço IP por engano investigando o software. A máscara de rede também deve ser correta.
O endereçamento de pacotes dentro da camada IP (onde a fonte e os endereços IP de destino se encapsulam na cabeçada IP) é outra fonte de problemas. A determinação de endereços IP de destino necessita comunicações com outra máquina, que deve manter a informação necessária. Se Domain Name System (DNS) for ativo, pode contribuir para a confusão se o servidor tiver mesas defeituosas.
É necessário para o endereço IP fazer-se o mapa ao endereço físico. Tanto ARP como RARP necessitam esta mesa a pacotes diretos sobre a rede. Se uma placa de rede se modificar por alguma razão, o endereço físico único no conselho já não corresponde ao endereço IP, portanto as mensagens se reencaminham em outro lugar. Os administradores de rede devem guardar a pista fechada de qualquer modificação do hardware de rede em todos os dispositivos.
Os problemas também podem ocorrer com dispositivos que tratam o encaminhamento intermediário, como pontes, encaminhadores e brouters. Estes devem estar sabendo todas as modificações da rede, bem como endereços físicos e lógicos dos dispositivos aos quais se unem. Os protocolos especializados como Routing Information Protocol (RIP) e Open Shortest Path First (OSPF) tratam a maior parte desta manutenção, mas em algum lugar na rede uma notação manual de modificações deve fazer-se.
Há muitas fontes potenciais de preocupação com a camada de rede. Mesmo os processos que devem trabalhar sem preocupação, como fragmentação de pacote e remontagem, podem causar problemas.
A conectividade entre máquinas tanto no transporte como em nível de rede pode testar-se usando a utilidade como silvo. Um cheque sistemático de máquinas ao longo de uma rede e fora sobre umas interredes pode ajudar a isolar problemas, não somente na fonte e máquinas de destino mas também em processadores intermediários como encaminhadores. A utilidade traceroute pode usar-se para isto, também, se estiver disponível.
A assunção da camada de rede funciona corretamente, o software de anfitrião de anfitrião poderia ser um problema. Se o software se instala corretamente e se começa (que poderia parecer óbvio mas é uma causa comum do fracasso), um processo para isolar o problema deve seguir-se. Há muitos arquivos implicados tanto com TCP como com UDP, que dissente com cada versão de sistema operacional, portanto a documentação que acompanha o software TCP ou UDP deve consultar-se.
O protocolo no uso deve determinar-se primeiro: a máquina usa TCP ou UDP, e se ambos, estiverem falhando ambos? Os problemas como demasiadas retransmissões ou nenhum valor de intervalo podem fazer UDP aparecer como se esteja falhando, mas TCP não se afetaria (a menos que use o mesmo porto ou demasiados processos são ativos).
Os endereços de porto podem ser problemáticos, especialmente com TCP. Cada porto em uma máquina pode enviar-se uma mensagem de silvo de uma máquina remota para verificar que se comunica propriamente. Se um pedido de porto falha, poderia indicar uma entrada imprópria ou ausente em um arquivo de configuração. A utilidade de dedo também poderia ser útil. Se as mensagens estiverem passando corretamente de uma máquina ao outro, o problema está na configuração do software ou aplicação de nível mais alto.
Os parâmetros de configuração incorretos podem causar TCP ou fracassos UDP. Por exemplo, se enviar e recebe valores de janela de TCP estabelecem-se em níveis baixos, não poderia haver oportunidade para aplicações para passar bastante informação. Neste caso, poderia parecer que TCP tem culpa. Cuidadosamente verifique todos os arquivos de configuração e colocações.
Supondo que tanto IP como TCP ou UDP estejam funcionando propriamente, a camada de aplicação é suspeito. Está nesta camada que os protocolos de nível mais alto como File Transfer Protocol (FTP), Telnet e SMTP se baseiam. Pode ser difícil encontrar problemas dentro da camada de aplicação, embora alguns testes simples ajudem a eliminar soluções óbvias. Vária utilidade comercial está disponível para controlar a recepção dentro da camada de aplicação.
A assunção que os dados vêm à aplicação direita (que pode verificar-se com alguns instrumentos diagnósticos ou rotinas de programação simples), o problema poderia estar na interpretação. Verifique que as comunicações entre duas aplicações são ambos o mesmo formato. Mais de uma aplicação esperou ASCII e recebeu EBCDIC. A diagnóstica mostra as mensagens que se movem na aplicação propriamente, mas são a linguagem inarticulada total à aplicação quando tenta interpretá-los.
A assunção que não é o problema, pode haver uma falta com as aplicações em qualquer fim. Embora pudesse supor que um programa Telnet de um vendedor falasse um de outro vendedor, isto não é verdade em um infelizmente grande número de casos. Se não houver pacotes de software idênticos ou as versões conhecidas trabalhar com outro pacote, isto pode ser difícil de investigar. Esta espécie do problema transversal aplicado é especialmente prevalecente com sistemas de plataforma variada, como um FTP BASEADO NO PC ou pacote de software TCP/IP que tenta acessar serviços em um anfitrião de UNIX.
Alguma utilidade prontamente disponível pode usar-se para controlar a camada de aplicação. Um pouco desta utilidade distribui-se com sistemas operacionais, e os outros distribuem-se como software de domínio público. A utilidade snmpwatch é um programa de monitorização de rede que informa em qualquer variável SNMP que modifica os seus valores. Isto pode ser útil em diagnosticar problemas de comunicações dentro de SNMP.
A Maçaroqueira de Internet é um programa de monitorização de rede que permite testar de vários protocolos, inclusive Telnet, FTP e SMTP. Infelizmente, não trabalha com todas as variantes de sistema operacional. Outro instrumento da prova de SMTP é mconnect, que verifica conexões.
Isto não é o lugar de um discurso longo na segurança de computador. Em vez disso, faço menção da segurança de impacto tem em redes TCP/IP-based só nos termos mais leves. A segurança é uma questão importante e um muitas vezes contemplado do alto, normalmente ao administrador arrependem-se. Tomar as medidas para fundar uma política de segurança própria e proteger o sistema bem como possível devem ser uma tarefa obrigatória de cada administrador de sistema.
Os encaminhadores podem ser significantes no plano de segurança de uma rede. A maior parte de encaminhadores permitem ao administrador de sistema restringir o tráfego pelo encaminhador em alguma maneira, em uma direção ou em ambos. Um encaminhador pode fazer-se, por exemplo, para proibir Telnet ou pedidos de rlogin do exterior da rede, mas permitir por meio de pedidos de transferência de arquivos como FTP. Os encaminhadores também podem prevenir o tráfego em uma rede local pelo encaminhador de qualquer lugar do lado de fora da rede, que reduz no acesso em (e por) uma rede.
Os encaminhadores normalmente executam este tipo da filtração de tráfego olhando simplesmente para as cabeçadas de datagrama do porto solicitado. Se um dos portos restringidos se solicitar, o datagrama pode devolver-se ao remetente ou descartar-se. Colocar os filtros de acesso próprios de um encaminhador de rede pode ser uma maneira eficaz e simples da restrição do lado de fora do acesso.
Infelizmente, a Internet e a maior parte de redes simplesmente não se projetaram para prevenir o acesso não autorizado ou a monitorização. Estas características acrescentavam-se normalmente distraidamente, e como tal têm alguns problemas. Olhando tráfego de rede e endereços capturam, as carteiras de identidade de usuário e as senhas são ridiculamente fáceis, portanto MIT desenvolveu protocolos de segurança de Kerberos à ajuda.
Kerberos (chamado como o cão de três cabeças que guarda as portas de Hades) usa uma chave de criptografia e método de introdução de servidor para permitir o acesso. Kerberos está lentamente adotando-se como um padrão entre usuários de Internet (apesar de alguns protestos governamentais), e trabalha bem com a família TCP/IP de protocolos. Para obter mais informações sobre Kerberos, una-se a ATHENA.MIT.EDU pela Internet ou envie o e-mail àquela informação sobre solicitação sobre sítio.
Tomei um relance na gestão de rede e instrumentos de resolução de problemas disponíveis com TCP/IP. Como mencionado na introdução, ambos os sujeitos são complexos, potencialmente exigentes, e ainda considerados por muitos ser uma arte. Há muitos livros excelentes sobre a gestão de rede, portanto você estimulam a esfregar a sua biblioteca ou livraria de que o interessam se quiser saber mais sobre este sujeito.
Os instrumentos fornecidos dentro da família TCP/IP dão-lhe bastantes recursos diagnósticos para isolar a fonte de praticamente qualquer software ou problema de hardware. Às vezes a solução para um problema é simples e pode dirigir-se facilmente por uma modificação de configuração. Muitas vezes, entretanto, um problema é do lado de fora dos limites do protocolo de TCP/IP, necessitando procedimentos diagnósticos mais potentes. É útil seguir os passos delineados neste capítulo primeiro e recorrer a outros sistemas só quando a diagnóstica TCP/IP foi incapaz de ajudar.
A administração de sistemas e a resolução de problemas de rede são ambos tarefas curiosas. Necessitam muito trabalho de vez em quando, mas há uma sensação de satisfação inegável quando uma rede corre lisamente ou foi no encalço e fixou um problema. Embora só alguns usuários em cada grupo se invoquem para executar qualquer tarefa, aqueles que fazem estão em para uma aventura verdadeira!
Segundo o Modelo de referência OSI, qual é o papel da gestão de falta?
A gestão de falta é a detecção, isolação e correção de faltas. Também inclui a manutenção e a verificação de erro e logs diagnósticos. A gestão de falta é uma de cinco gestão Específica áreas Funcionais definidas pela OIS como parte do OSI-RM.
O que são CMIP e CMIS? Como se relacionam a SNMP?
CMIP é o Protocolo de informação de gestão Comum. CMIS é o Serviço de informações de gestão Comum. Ambos são parte da proposta de gestão de rede OSI do uso como uma substituição de SNMP.
Com SNMP, o que é a gestão por procuração?
A gestão por procuração é quando um dispositivo que não pode manter o software de reagente SNMP cheio e base de informação de gestão (MIB) manda controlar aquela informação por outra máquina (a sua procuração). A procuração comunica-se com o dispositivo que se dirige. Um exemplo típico é impressora anexada a uma estação de trabalho. A estação de trabalho atua como a procuração da impressora porque a impressora não tem software de controle com ele.
O que quatro utilidade fornece o TCP/IP básico resolução de problemas de informação?
A quatro utilidade o mais comumente usada para investigar uma rede TCP/IP é o silvo, o dedo, ruptime, e netstat.
Quando usaria a utilidade traceroute?
A utilidade traceroute usa-se para enviar datagramas UDP a uma máquina de objetivo, um pulo de uma vez. A produção de traceroute mostra cada máquina que adiante a mensagem, permitindo-lhe seguir a via para isolar um problema.