1. Linhas Privadas

Uma ou mais Linhas Privadas (LPs) farão a ligação do PA com outro PA ou com um Ponto de Presença (POP) regional ou federal. É importante a existência de pelo menos uma linha dedicada à Internet permitindo o recebimento e envio de pacotes a qualquer instante. Ao contratar uma LP de uma Entidade Exploradora de Serviços Públicos de Telecomunicações (EESPT) é pago um valor fixo mensal, independentemente da utilização da linha.

A LP de menor capacidade recomendada para ligação de um PA à Internet é de 64Kbps. Consulte uma EESPT local acerca de disponibilidade, prazos e tarifas para LP's dessa velocidade ou velocidades superiores.

Em geral, deve-se solicitar uma LP síncrona especializada, onde os modems são fornecidos pela empresa que fornece o serviço de LP. Será necessário que o roteador ao qual a linha se conectará possua uma interface síncrona que suporte a velocidade da LP.

2. Roteadores

Este é o equipamento que fará o roteamento de pacotes da sua rede local para a Internet e vice-versa. A ele é atribuída a responsabilidade de manutenção e atualização das informações de roteamento

A melhor opção aqui, do ponto de vista técnico, é a utilização de equipamentos dedicados projetados especificamente para roteamento, que são conhecidos como roteadores dedicados. É importante que o roteador escolhido seja realmente compatível com o roteador do ponto ao qual o PA estará ligado. Para tanto, entre em contato com o responsável técnico da instituição que proverá acesso ao seu PA.

Uma opção mais barata, embora menos eficiente e segura, é a utilização de servidores Unix como roteadores . Outras opções alternativas são a utilização de roteadores públicos como o ka9q e o PCRoute, executando em computadores pessoais da linha IBM.

É importante definir o roteador em função do tráfego previsto. O seu roteador deverá ter um desempenho suficiente para encaminhar o fluxo de pacotes de cada interface a ele ligada. É comum a especificação do desempenho de um roteador em pacotes por segundo (pps), sendo utilizados pacotes de 64 Kbytes. Para o dimensionamento do roteador deveremos estimar com folga o fluxo gerado por cada interface.

Uma interface serial de 64 kbps gerará sempre um fluxo de no máximo 125 pps. Uma interface E1 gerará no máximo 32 vezes isso. E assim por diante. Para estimar o fluxo gerado por interfaces de redes locais, como Ethernets e FDDIs utilizamos os dados medidos em laboratório, encontrados em:

Assim temos a seguinte tabela de fluxo por tipo de interface:

        Interface                Desempenho [pps]        
 64 Kbps                                125      
 E1 (2 Mbps)                           4000       
 Ethernet (10 Mbps)                    3100       
 Ethernet (100 Mbps)                  31000        
 FDDI  (100 Mbps)                     98000        

Devemos considerar que um roteador conseguirá rotear de uma interface, no máximo, o fluxo correspondente à soma do fluxo das outras interfaces. Desta forma, se tivermos, por exemplo, um roteador com duas interfaces de 64 Kbps (2 x 125 pps) e uma Ethernet 10baseT (3100 pps), o fluxo máximo da Ethernet que poderá ser absorvido pelo roteador será o de 250 pps. Assim, um roteador com um Ehternet 10baseT e duas seriais de 64Kbps deverá ter um desempenho de pelo menos 500 pps.

No Brasil, as interfaces apropriadas do roteador para conexão ao(s) modem(s) da(s) sua(s) LP(s) e à sua rede local, para linhas de baixa velocidade utilizam-se interfaces V.36 ou V.35. A V.36, padrão europeu, tem uma relação Taxa x Distância melhor. A V.35, padrão americano, utiliza menos condutores. Em geral as LPs nacionais utilizam interfaces V.36. Na dúvida, adquira o seu roteador com capacidade para V.35 e V.36, já que o custo adicional (um cabo, no caso de Cisco) é baixo em relação ao custo total do equipamento. As interfaces de velocidade mais alta (isto é, acima de 64 Kbps) utilizam o padrão G.703.

Consulte sempre o seu fornecedor de roteadores para especificar o modelo que adequa-se às suas necessidades atuais e futuras.

Ka9q

O Ka9q NOS11 é um sistema operacional de redes, disponível para equipamentos tipo PCs. Instalado sobre o DOS, pode ser configurado para implementar ou viabilizar os seguintes serviços:

O pacote foi desenvolvido por Phil Karn e é muito utilizado como roteador, principalmente por permitir ser utilizado em equipamentos de baixo custo. É capaz de fazer roteamento entre Ethernet e linhas seriais, podendo utilizar SLIP ou PPP. Implementa ainda o protocolo SNMP para gerência de rede.

Os requisitos mínimos para instalação do Ka9q NOS11C-A são um microcomputador 386SX e 2 Mbytes de RAM. É recomendado utilizar um disco com memória cache de 512-1024 Kbytes (SMARTDrive 4.0 para Windows 3.1).

Referências:

http://inorganic5.chem.ufl.edu/ka9q/ka9q.html
http://ec4.tachemie.uni-leipzig.de/0c:/rechner.html
http://www.cc.ukans.edu/hytelnet_html/ESCAPE.KEY.html
gopher://boombox.micro.umn.edu:70/11/gopher/PC_server
gopher://boombox.micro.umn.edu/00/gopher/PC_server/ 00README

Repositórios:

ftp://sun.soe.clarkson.edu/pub/ka9q
ftp://minnie.cs.adfa.oz.au/hamradio/packet/nos

PCRoute

O PCRoute é um software desenvolvido por Vance Morrison <morrison@casbah.acns.nwu.edu> para PCs XT/AT ou similares, e implementa roteamento IP. Exige como hardware adicional apenas as placas de rede, o que torna o custo total bastante reduzido. Geralmente é utilizado para roteamento de redes Ethernet, embora essa não seja a única configuração possível.

Atualmente, o PCRoute suporta as seguintes interfaces:

Cabe ressaltar que o protocolo SNMP não é suportado.

Referências:

http://www.psg.com/toolkits.html
http://www.zilker.net/users/internaut/leased.html
http://www.math.niu.edu/~behr/docs/mactcp.html
http://src.doc.ic.ac.uk/packages/ibmpc
gopher://gopherhost.ots.utexas.edu/00/netinfo/ethernet/pkt-drvrs/ pkt-drvr-apps

Repositórios:

ftp://archive.orst.edu/pub/mirrors/simtel/msdos/cad/00_index.txt
ftp://ftp.lrz-muenchen.de/pub/comp/platforms/pc/pcbridge
ftp://ftp.biochem.mpg.de/pc/isdn/ispa.README
ftp://ftp.biochem.mpg.de/pc/isdn/
ftp://src.doc.ic.ac.uk/pub/packages/ibmpc/
ftp://ftp.demon.co.uk/pub/ibmpc

3. Servidore de Comunicação

O Servidor de Comunicação (SC) cuida do acesso dos usuários ao seu PA via Linhas Discadas (LDs).

Por um lado,o seu servidor terá uma interface com os modems, utilizando-se, em geral, de interfaces RS-232C. Há SCs que já possuem os modems internamente, em cujo caso a interface será diretamente a linha telefônica (RJ-11 ou tomada Telebrás). Do outro lado, o SC deverá ter uma interface para a rede que você estiver utilizando.

A melhor opção, novamente do ponto de vista técnico, é a utilização de SCs especializados, que são equipamentos projetados apenas para essa função.

Uma opção mais barata, embora menos eficiente, pode ser a utilização de servidores Unix com uma ou mais placas multiseriais, como SC.

4. Gateway X.25

Um gateway X.25 possibilita a ligação de seu PA com a Rede Nacional de Pacotes (RENPAC) ou outras redes X.25 públicas ou privadas. A ligação X.25 é útil para que usuários localizados em cidades distantes do seu PA tenham uma forma alternativa para conexão, que não seja utilizando ligações telefônicas de ponta a ponta. Ela pode ser utilizada também para acesso a bases de dados no X.25.

Como gateway X.25 existem três opções: (1) utilizar o seu roteador; (2) utilizar o SC; ou (3) utilizar o servidor Unix. O uso de qualquer uma delas irá depender da capacidade do seu equipamento de trabalhar com X.25. No servidor Unix, em geral, vendem-se drivers separados para X.25. Porém, existem servidores públicos alternativos como o FreeBSD e o NetBSD que já suportam o protocolo X.25 .

5. LD

As LDs são, em princípio, linhas telefônicas comuns que serão usadas para receber ligações de usuários feitas através dos seus computadores. Este tipo de acesso é conhecido como Acesso Discado (AD).

No AD é importante dimensionar o número de linhas em função da quantidade de usuários do PA. Considerando uma política de acesso onde o tempo é ilimitado, é recomendável que a relação número de usuários/linha não seja superior a 10. É claro que este valor deverá ser ajustado em função do perfil dos usuários e, para tanto, se faz necessário que o uso das linhas seja devidamente monitorado.

6. Modems

Modems para AD serão necessários quando o seu SC não possuir modems internamente. Em ambos os casos, devem-se utilizar modems padrão V.34 c/ V.42bis.

O V.34 utiliza a taxa de transmissão de 28.800 bps. Os V.42 e V.42bis permitem, respectivamente, a correção e compactação dos dados no próprio modem. Uma opção mais barata é o V.32bis c/V.42bis e V.42. O V.32bis utiliza a taxa de transmissão de 14.400 bps. É indispensável que estes modems tenham a facilidade de atender chamadas telefônicas. Por outro lado, é desejável que eles trabalhem também com taxas mais baixas, como V.22bis (2400) e V.22 (1200), para atender, ainda que precariamente, aqueles usuários que não dispõem de modems de maior capacidade.

7. Servidores

A Internet baseia-se no modelo cliente-servidor no qual uma máquina, chamada de "servidor" tem por função básica tornar disponível um determinado serviço, que será acessado por uma outra máquina, denominada "cliente".

Servidor, a rigor, é um processo que implementa um determinado serviço, como por exemplo: servidor de correio eletrônico (sendmail), servidor de listas (listserv/marjordomo), servidor Gopher (gopherd), servidor de news (nntpd), servidor Web (httpd), servidor de impressão (lpd), servidor de sistema de arquivos (nfsd), servidor de nomes ou DNS (named), dentre outros.

Uma prática comum, em redes locais ou em sites não muito grandes, é centralizar-se os vários serviços em uma única máquina servidora.

Pode-se ter diversas combinações de hardware/software para um servidor, desde um PC 486 com um sistema operacional como Netware, Windows NT, NetBSD ou Linux, até uma estação de trabalho incrementada executando Solaris. No entanto, recomenda-se a utilização do sistema operacional Unix no servidor, por este ser o padrão de fato em redes no mundo.

Durante a implantação de um PA, recomenda-se a instalação dos seguintes servidores :

Hardware

O leque de opções para servidores é bastante vasto, desde supercomputadores, passando por estações de trabalho e chegando até os PCs. Qualquer que seja a sua opção, lembre-se que você deverá utilizar servidores com bastante memória, com discos e barramentos velozes.

Cabe ressaltar que a capacidade dos discos será um fator limitante em função do número de usuários, isto porque as mensagens recebidas via correio eletrônico ficarão guardadas nos discos dos seus servidores até que sejam lidas pelo usuário. Algumas sugestões são:

Sistemas Operacionais

São listados a seguir os sistemas operacionais freqüentemente utilizados em servidores, acompanhados pela respectiva lista de referências:

Referências:

AIX

http://www.ibm.com

FreeBSD

http://www.freebsd.org
ftp://ftp.freebsd.org

FAQs

http://www.freebsd.org/How/faq

Linux

http://www.linux.org

Newsgroups:

news:comp.os.linux
news:comp.os.linux.admin
news:comp.os.linux.advocacy
news:comp.os.linux.announce
news:comp.os.linux.answers
news:comp.os.linux.development
news:comp.os.linux.development.apps
news:comp.os.linux.development.system
news:comp.os.linux.hardware
news:comp.os.linux.help
news:comp.os.linux.misc
news:comp.os.linux.networking
news:comp.os.linux.setup
news:comp.os.linux.x

NetBSD

http://www.netbsd.org
ftp://ftp.netbsd.org

Listas:

http://www.netbsd.org/MailingLists/index.html

Newsgroups:

news:comp.os.386bsd.announce
news:comp.os.386bsd.apps
news:comp.os.386bsd.bugs
news:comp.os.386bsd.misc
news:comp.os.386bsd.questions

Netware

http://www.novell.com
ftp://ftp.novell.com/pub/netware
gopher://gopher.novell.com

Newsgroups:

news:comp.os.netware.announce
news:comp.os. netware.connectivity
news:comp.os. netware.misc
news:comp.os. netware.security

OS/2

http://www.ibm.com

Newsgroups:

news:comp.os.os2
news:comp.os.os2.advocacy
news:comp.os.os2.announce
news:comp.os.os2.apps
news:comp.os.os2.beta
news:comp.os.os2.bugs
news:comp.os.os2.comm
news:comp.os.os2.games
news:comp.os.os2.mail-news
news:comp.os.os2.marketplace
news:comp.os.os2.misc
news:comp.os.os2.multimedia
news:comp.os.os2.networking
news:comp.os.os2.networking.misc
news:comp.os.os2.networking.tcp-ip
news:comp.os.os2.networking.www
news:comp.os.os2.programmer
news:comp.os.os2.programmer.misc
news:comp.os.os2.programmer.cop
news:comp.os.os2.programmer.porting
news:comp.os.os2.programmer.tools
news:comp.os.os2.setup
news:comp.os.os2.setup.misc
news:comp.os.os2.setup.storage
news:comp.os.os2.setup.video
news:comp.os.os2.utilities
news:comp.os.os2.ver1x

OSF/1

http://www.digital.com
ftp://ftp.digital.com/pub/Digital/OSF1

SCO UNIX

http://www.sco.com
ftp://ftp.sco.com/SCO

Solaris

http://www.sun.com

SunOS

http://www.sun.com

WindowsNT

http://www.microsoft.com
gopher://gopher.microsoft.com
ftp://ftp.microsoft.com

Estações

Estações são os equipamentos de uso geral de operações de um PA. Elas podem ser desde estações de trabalho Unix até Pcs com DOS ou OS/2. O leque de opções disponíveis no mercado brasileiro é o mais amplo possível.

7. ACESSO À REDE

Em seguida, são descritos aspectos relacionados ao acesso à Internet, isto é, ao PA, pelo usuário. O acesso caracteriza-se pela forma (dedicado, discado e X.25) e pelo tipo de enlace adotado (IP Falso, PPP, SLIP ou terminal).

Quanto à conexão

A conexão física pode ser de dois tipos: dedicada ou discada, descritas a seguir.

1. Conexão Dedicada

Em geral uma conexão dedicada é utilizada por usuários que possuem uma rede local e não apenas uma máquina ligada à linha telefônica. Nesses casos, justificam-se custos adicionais, associados à manutenção de uma conexão dedicada, pelo número de usuários beneficiados pelo serviço, pelos tipos de serviço de rede viabilizados ou por razões comerciais (veja o Guia do Empreendedor Internet/Brasil).

A LP utilizada vai depender da capacidade do PA, da necessidade do usuário e da disponibilidade da EESPT. É inútil, para ter acesso a um PA, utilizar uma LP com maior capacidade do que a LP do PA para o resto da rede. A opção mais econômica é a utilização de uma LP não especializada, em que a EESPT entrega apenas um par de fios, e cabe ao usuário e ao PA a responsabilidade pela compra e instalação dos modems. Nesse caso, em função da qualidade da linha, devem-se utilizar modems V.34/V.42bis que aceitem ser configurados para LP.

Preferencialmente as LPs devem ser ligadas a roteadores dedicados pois garantem maior confiabilidade à ligação. Uma alternativa é a utilização de um SC como roteador.

O protocolo de enlace utilizado deve ser comum aos dois extremos da conexão, tais como: HDLC, SDLC, opcionalmente PPP, ou, em última opção, SLIP . Esta escolha dependerá da disponibilidade do serviço nas duas pontas.

2.Conexão Discada

O acesso discado em geral é utilizado por um usuário individual, através de um microcomputador com modem ligado à rede telefônica. No PA, o SC é configurado para que o acesso seja feito utilizando-se um ou mais dos seguintes serviços:

ou shell Unix.

Quanto ao enlace

Após o estabelecimento da conexão física, necessitamos de um protocolo que controle o acesso a esta conexão, isto é, que controle o fluxo de pacotes IPs pela linha serial. Com esta função destacamos o False IP; o PPP e o SLIP.

3. False IP

a) TIA

O TIA, The Internet Adapter, possibilita o uso de aplicativos que requerem uma ligação do tipo TCP/IP, tais como Netscape e Eudora, através de uma conta Unix padrão, convertendo-a em uma conta "pseudo-SLIP".

É um programa executado no servidor onde está localizada a conta Unix, que redireciona internamente pacotes TCP/IP para o computador do usuário, através do protocolo SLIP, onde residem os programas clientes.

O usuário final poderá, também, utilizar o Kit de Acesso Via Linha Discada (Versão do Usuário Final), disponível em setembro de 95, quando o seu provedor lhe oferecer um acesso False IP.

Referências:

http://marketplace.com/tia/tiahome.html
http://www.webcom.com/~llarrow/tiarefg.html
http://marketplace.com/tia/encompass/encwin.html

Listas:

Para obter informações sobre o TIA, envie mensagem para:

tia-directory@marketplace.com

Repositórios:

ftp://marketplace.com/tiabeta/<modelo do servidor>.tia
ftp://marketplace.com/tia/encompass/encwin.exe

b) SLiRP

É um emulador de SLIP (Serial Line Internet Protocol), funcionalmente equivalente ao TIA. É capaz de implementar uma conexão SLIP a partir de uma conexão tipo terminal remoto a uma conta Unix, possibilitando a utilização de aplicativos como NCSA Mosaic, Netscape Navigator, OS/2's Web Explorer, Quarterdeck Mosaic ou Kit de Acesso Via Linha Discada (Versão do Provedor de Serviços), disponível em agosto de 95.

Referências:

http://blitzen.canberra.edu.au/~danjo/
http://www.wit.com/~danjo/
http://pr.erau.edu/~vanerj/slirp.html

Repositórios:

ftp://blitzen.canberra.edu.au/pub/slirp

4. PPP

O Point-to-Point Protocol (PPP) provê um método de transmitir datagramas por uma linha serial de forma confiável, isto é, sem perdas nem embaralhamento da informação. O PPP encontra-se implementado numa vasta gama de arquiteturas: Windows, a maioria dos Unixs, CSs e roteadores dedicados.

O procedimento de instalação e configuração do PPP depende da plataforma utilizada. Roteadores e CSs geralmente suportam o PPP (verifique na própria documentação do produto a disponibilidade e como habilitá-lo). Nos sistemas operacionais BSDs que não têm o PPP embutido como o SunOS, por exemplo, pode-se instalar o pppd.

Referências:

RFCs:

  • RFC1144: Jacobson, V. Compressing TCP/IP headers for lowspeed serial links. 1990 February.
  • RFC1321: Rivest, R. The MD5 Message-Digest Algorithm. 1992 April.
  • RFC1332: McGregor, G. PPP Internet Protocol Control Protocol (IPCP). 1992 May.
  • RFC1334: Lloyd, B.; Simpson, W.A. PPP authentication protocols. 1992 October.
  • RFC1548: Simpson, W.A. The Point-to-Point Protocol (PPP). 1993 December.
  • RFC1549: Simpson, W.A. PPP in HDLC Framing. 1993 December.
  • Repositórios:

    ftp://ftp.ci.rnp.br/pub/packages/ppp

    5. SLIP

    O SLIP (Serial Line Internet Protocol) permite a transmissão de pacotes TCP/IP através de uma linha serial.

    Referências:

    http://www.cis.ufl.edu/help-system/slip-stuff/

    http://www.micro.umn.edu/products/slip/slip.html

    http://reality.sgi.com/employees/scotth/dialup_support.html

    6. X.25

    Em geral o gateway X.25 é feito em um servidor Unix, sendo necessário para isso verificar com o fornecedor do seu Unix a disponibilidade de drivers X.25. Alguns roteadores também possibilitam a conexão com uma rede X.25.

    Sobre o X.25 pode-se usar como protocolo de enlace:

    ou shell Unix.

    8. SERVIÇOS BÁSICOS

    Aqui introduzimos os serviços básicos de uma rede ligada à Internet. São eles: roteamento, DNS, correio eletrônico e gerência de redes .

    1. Roteamento

    A infra-esturtura física de uma grande rede de computadores pode ser comparada a uma estrutura rodoviária. As cidades seriam as instituições, com seus diversos computadores e redes locais, e as rodovias os canais de comunicação, interligando essas instituições.

    Quando consultamos um mapa rodoviário conhecemos os vários caminhos possíveis de ligação entre as cidades. Se a nossa intenção é fazer uma viagem, procuramos escolher o melhor caminho. No universo das redes a mesma coisa acontece, ou seja, dentre os diversos caminhos possíveis de comunicação entre computadores, tenta-se usar o melhor segundo um conjunto de critérios.

    A atividade de encaminhamento de unidades de informação (pacotes) por essa estrutura de rede recebe o nome de roteamento. O caminho de comunicação é conhecido como rota.

    Imagine que o computador A deseja estabelecer uma conexão com o computador B, e cada ponto indicado por um numero seja um nó dessa rede de computadores.

    Em algumas tecnologias de rede, o caminho inicial escolhido para a conexão pode ser alterado, durante a comunicação entre os sistemas. Isso evita que uma comunicação seja interrompida devido a uma falha em algum nó ou uma queda em algum dos canais de comunicação.

    Na tecnologia TCP/IP, o roteamento é feito com base em números de rede IP e em tabelas de roteamento.

    Por exemplo:

        rede                       destino            
     200.6.48.0                 ethernet serial2        
     192.153.200.0              200.6.48.6 serial5       
     200.19.20.0                                              
     default                                                  
    

    Nessa pequena tabela as seguintes informações são apresentadas: sistemas da rede 200.6.48 são conectados via ethernet (rede local); os sistemas 192.153.155.1, 192.153.155.2,..., são acessíveis via interface serial 2 (uma conexão SLIP por exemplo); do host 200.6.48.6 (máquina que atua como gateway) se chega à rede 200.19.20; finalmente, para qualquer outro endereço de rede, o destino é a interface serial 5.

    Formas de Roteamento

    Basicamente existem duas formas de roteamento em uma rede de computadores: o roteamento estático e o roteamento dinâmico.

    No primeiro, as rotas de comunicação são estabelecidas previamente e não são alteradas, a não ser por intervenção de um operador, durante a comunicação.

    Esse tipo de roteamento só é viável em redes pequenas e estáveis do ponto de vista de crescimento e mudanças. A vantagem dessa forma é a simplicidade de implementação (desde que a rede seja pequena).

    No roteamento dinâmico as rotas são determinadas e atualizadas continuamente, em pequenos intervalos de tempo (três minutos, por exemplo). A determinação do melhor caminho é feita através do uso de um protocolo de troca de informações de roteamento entre os nós envolvidos no processo (os roteadores) e da aplicação de um algoritmo de escolha de rota.

    A maior dificuldade nesse tipo de roteamento é a escolha correta das fontes de informação de roteamento. Se a definição não é bem feita corre-se o risco de divulgação de rotas inconsistentes e erradas, colocando em risco toda a rede.

    A escolha de uma rota pode levar em conta a distância (em termos de número de nós percorridos), o tempo gasto na comunicação, a capacidade de transmissão do canal, a confiabilidade do meio de transmissão e outros.

    Na tecnologia TCP/IP existem dois grandes grupos de protocolos de roteamento: os de roteamento interior e os de roteamento exterior. O conceito por trás destes dois tipos é o de sistema autônomo.

    Um sistema autônomo consiste de múltiplas redes e roteadores subordinados a uma única autoridade administrativa. Dentro de um sistema autônomo define-se o tipo de roteamento e a forma como ele será implementado. Esse é o roteamento interior.

    O roteamento exterior consiste da troca de informações de roteamento entre diferentes sistemas autônomos.

    Representando o primeiro grupo temos os protocolos RIP, HELLO, OSPF e outros. No segundo grupo, o mais utilizado atualmente é o BGP4.

    Referências:

    RFCs:

    RFC-1180: Roteamento na Internet
    Conceitos Básicos (tutorial de TCP/IP)
    Protocolos de Roteamento na Internet
    RIP - RFC-1058 e RFC-1723 (RIP2)
    OSPF - RFC-1583
    BGP - RFC-1654 a RFC-1657 (BGP4), RCF-1267 (BGP3)

    Implementação em Sistemas Unix

    routed (RIP): man routed
    gated (RIP1/2, HELLO, OSPF, EGP e BGP1/2/4):

    Bibliográficas:

    COMER, D., Internetworking With TCP/IP, Prentice-Hall

    Repositório:

    ftp://gated.cornell.edu (Gated)

    2. DNS

    Nesta seção fazemos uma introdução ao serviço de nomes da Internet, o chamado Domain Name System (DNS), e ao procedimento de registro de redes e domínios da INTERNET/BR.

    O DNS é o serviço Internet que tem como objetivo principal a conversão de nomes de máquinas em endereços IPs e vice-versa. As máquinas são agrupadas em domínios, que podem estar contidos em outros domínios, formando assim uma estrutura hierárquica, análoga a uma estrutura de diretórios usada em alguns sistemas operacionais. Nesta analogia, um domínio corresponde a um diretório, e um arquivo corresponde a uma máquina. Por exemplo, o nome www.ci.rnp.br denomina a máquina WWW do domínio ci.rnp.br, e o domínio ci.rnp pertence ao domínio br.

    Este serviço possui uma base de dados distribuída, controlada por servidores de nomes (DNS servers), como o BIND (seção 4.2.2). Cada domínio deve ter um servidor primário e um ou mais servidores secundários. O servidor primário é o responsável pelas informações sobre o seu domínio. Os servidores secundários apenas mantém as informações obtidas junto ao servidor primário de um domínio, cuidando de atualizar esta informação periodicamente, sempre que necessário.

    A base de dados do DNS pode ser vista como um único domínio raíz ("."), equivalente ao "/" do Unix. Ligado diretamente ao "." temos um subdomínio para cada país. Assim "br", para Brasil, "ar", para Argentina, etc. Dentro do "br" há subdomínios em função da natureza da atividade desenvolvida pela instituição. Assim, temos:

    Os domínios com, edu, gov, mil, net, org e us, são americanos. O domínio arpa.in-addr abriga os subdomínios de endereços IPs, também chamados de domínios reversos. Enquanto os domínios diretos são utilizados para localizar os endereços IPs de uma máquina conhecendo-se um dos seus nomes, o domínio reverso é utilizado para localizar o nome de uma máquina conhecendo-se um dos seus endereços IPs.

    Para que o DNS funcione, é preciso que o servidor de um determinado domínio conheça todos os seus subdomínios, bem como quais são seus servidores e quais os seus respectivos endereços IPs. O processo de identificação de um novo domínio em um servidor é chamado de registro. Em seguida abordaremos os processos de aquisição de endereços IPs e registro no DNS.

    Aquisição de Endereços IPs e Registro no DNS

    A seguir são indicados os procedimentos necessários para realizar a ligação de uma subrede à INTERNET/BR. São eles:

    Aceitação do Termo de Adesão

    O Termo de Adesão, disponível via

    ftp://ftp.ci.rnp.br/doc/adesao.as

    deve ser conhecido e aceito pela sua instituição.

    Solicitação de Endereços IPs

    A utilização de endereços oficiais é indispensável para realizar a ligação de máquinas à Internet. Posto que duas máquinas não podem ter o mesmo endereço, e que todo o roteamento de pacotes, nos backbones, é feito por blocos de endereços, torna-se necessário que uma máquina, ligada à INTERNET/BR, utilize um endereço destinado a esta rede.

    A obtenção de endereços oficiais é, portanto, requisito indispensável para ligação de uma rede à Internet.

    Endereços IPs oficiais devem ser solicitados ao provedor de acesso ao qual sua rede está ou irá conectar-se. O formulário de solicitação para aquelas redes que estarão ligadas diretamente à INTERNET/BR encontra-se em:

    http://www.ci.rnp.br/doc/formularios/req-ip.html

    Os provedores de acesso podem e devem basear-se nesse formulário para construir o Formulário de Solicitação de Endereços IPs que será utilizado por seus usuários.

    Para informações adicionais, consulte o Centro de Informações da RNP.

    Registro no DNS

    De posse de endereços IPs oficiais, um servidor DNS deve ser configurado como servidor do seu domínio (seção 4.2.2), para posteriormente ser solicitado o registro respectivo.

    A solicitação de registro do seu domínio no DNS deve ser feita ao Centro de Operações responsável pelo servidor do domínio imediatamente superior. Assim, se seu domínio for meu-dep.empresa.com.br, você deve encaminhar a solicitação ao responsável pelo domínio empresa.com.br.

    Para os domínios que ficarão registrados diretamente ao br, com.br, gov.br, mil.br, net.br e org.br, deve ser utilizado o Formulário de Registro de Domínios no DNS, disponível via

    http://www.ci.rnp.br/doc/formularios/ reg-dns.html.

    Os responsáveis por outros domínios podem utilizá-lo como modelo para fazer o formulário que será utilizado pelos seus usuários para solicitação de registro de subdomínios.

    A solicitação de registro no DNS deve ser feita apenas após a disponibilização de endereços IPs oficiais e após a correta configuração do seu servidor de nomes. Portanto você deve aguardar o recebimento desses endereços antes de solicitar o registro no DNS.

    O endereço do responsável por determinado domínio pode ser encontrado utilizando-se do comando nslookup, do Unix, da seguinte forma:

            
    nslookup

    > server 143.108.1.17

    Default Server: dixit.ansp.br

    Address: 143.108.1.17

    > set type=soa

    > fapesp.br

    Server: dixit.ansp.br

    Address: 143.108.1.17

    fapesp.br

    origin = dixit.ansp.br

    mail addr = root.dixit.ansp.br

    serial = 95015500

    refresh = 7200 (2 hours)

    retry = 7200 (2 hours)

    expire = 3600000 (41 days 16 hours)

    minimum ttl = 86400 (1 day)

    >

    onde "fapesp.br" deve ser substituído pelo domínio desejado (exemplo, "empresa.com.br") e "root.dixit.ansp.br" indica que o endereço eletrônico do responsável técnico do domínio em questão é root@dixit.ansp.br.

    Registro no DNS do seu Domínio Reverso

    O registro do domínio reverso permitirá que uma máquina, conhecendo um endereço IP, consiga saber qual o nome completo (nome.domínio) correspondente a este endereço. Este registro é centralizado na Internet pelo InterNIC. O formulário de registro pode ser adquirido via:

    ftp://ftp.ci.rnp.br/doc/formularios/in-addr-template.txt

    e deve ser enviado para:

    hostmaster@internic.net.

    A solicitação de registro no DNS do seu domínio reverso deve ser feita apenas após o registro no DNS do seu domínio direto (procedimento anterior) ter sido concretizado.

    Servidor DNS

    O software servidor de DNS mais popular é o Berkeley Internet Name Domain (BIND), de Kevin Dunlap, o named. Portado para a maioria dos Unix, ele é distribuído, em geral, como parte integrante desses sistemas.

    Referências:

    Bibliográficas:

  • DNS and BIND, Livro de Paul Albitz e Cricket Liu cujo conteúdo é uma didática introdução ao BIND e onde podem ser encontrados detalhes sobre sua configuração.
  • Man-pages: named(8), resolv.conf(5) e nslookup (8) Albitz, Paul e Liu, Cricket. DNS and BIND. O'Reilly & Associates Inc, 1992, ISBN 1-56592-010-4. 381 pp.
  • Braden, R.T.; Postel, J.B. Requirements for Internet Gateways. Marina del Rey, CA: University of Southern California, Information Sciences Inst.; 1987 June; RFC 1009. 55 pp. (DS.INTERNET.NET POLICY RFC1009.TXT).
  • Garcia-Luna-Aceves, J.J.; Stahl, M.K.; Ward, C.A., eds. Internet Protocol Handbook: The Domain Name System (DNS) Handbook. Menlo Park, CA: SRI International, Network Information Systems Center; 1989, August; 219 pp. AD A214 698.
  • Gerich, E. Guidelines for Management of IP Address Space, Ann Arbor, MI: Merit Network, Inc.; May 1993; RFC 1466. 10 p. (DS.INTERNIC.NET RFC1466.TXT).
  • Harrenstien, K.; Stahl, M.K.; Feinler, E.J. DoD Internet Host Table Specification. Menlo Park, CA: SRI International, DDN Network Information Center; 1985 October; RFC 952. 6 p. (RS.INTERNIC.NET POLICY RFC952.TXT). Obsoletes: RFC 810
  • Harrenstein, K.; Stahl, M.K.; Feinler, E.J. Hostname Server. Menlo Park, CA: SRI International, DDN Network Information Center; 1985 October; RFC 953. 5 p. (NIC.DDN.MIL RFC:RFC953.TXT). Obsoletes: RFC 811
  • Internet Engineering Task Force, Braden, R.T. Requirements for Internet Hosts -- Communication Layers. Marina del Rey, CA: University of Southern California, Information Sciences Inst.; October 1989; RFC 1122. 116 p. (DS.INTERNIC.NET RFC1122.TXT).
  • Internet Engineering Task Force, Braden, R.T. Requirements for Internet Hosts -- Application and Support. Marina del Rey, CA: University of Southern California, Information Sciences Inst.; October 1989; RFC 1123. 98 p. (DS.INTERNIC.NET RFC1123.TXT).
  • Lottor, M. Domain Administrators Operations Guide. Menlo Park, CA:SRI International, DDN Network Information Center; 1987 November; RFC 1033. 22 p. (RS.INTERNIC.NET POLICY RFC1033.TXT).
  • Mockapetris, P. DNS Encoding of Network Names and Other Types. Marina del Rey, CA: University of Southern California, Information Sciences Inst.; 1989 April; RFC 1101. 14 p. (RS.INTERNIC.NET POLICY RFC1101.TXT). Updates: RFC 1034; RFC 1035
  • Mockapetris, P. Domain Names - Concepts and Facilities. Marina del Rey, CA: University of Southern California, Information Sciences Inst.; 1987 November; RFC 1034. 55 p. (RS.INTERNIC.NET POLICY RFC1034.TXT). Updated-by: RFC 1101 Obsoletes: RFC 973; RFC 882; RFC 883
  • Mockapetris, P. Domain names - Implementation and Specification. Marina del Rey, CA: University of Southern California, Information Sciences Inst.; 1987 November; RFC 1035. 55 p. (RS.INTERNIC.NET POLICY RFC1035.TXT). Updated-by: RFC 1101 Obsoletes: RFC 973; RFC 882; RFC 883
  • Mogul, J.; Postel, J.B. Internet Standard Subnetting Procedure. Stanford, CA: Stanford University; 1985 August; RFC 950. 18 p. (DS.INTERNIC.NET POLICY RFC950.TXT).
  • Postel, J.B.; Reynolds, J.K. Domain Requirements. Marina del Rey, CA: University of Southern California, Information Sciences Inst.; 1984 October; RFC 920. 14 p. (RS.INTERNIC.NET POLICY RFC920.TXT).
  • Reynolds, J.K.; Postel, J.B. Assigned Numbers. Marina del Rey, CA: University of Southern California, Information Sciences Inst.; 1992 July; RFC 1340. 139p. (DS.INTERNIC.NET POLICY RFC1340.TXT). [Note: the current version is always available as "STD 2".]
  • Rekhter, Y., Moskowitz. B., Karrenberg, D., de Groot, G. Address Allocation for Private Internets, IBM Corp., Chrysler Corp., RIPE NCC; March 1994; RFC 1597. 8 p. (DS.INTERNIC.NET RFC1597.TXT).
  • Stahl, M.K. Domain Administrators Guide. Menlo Park, CA: SRI International, DDN Network Information Center; 1987 November; RFC 1032. 14 p. (RS.INTERNIC.NET POLICY RFC1032.TXT).
  • Repositório:

    ftp://ftp.uu.net/networking/ip/dns/bind.

    3. Correio Eletrônico

    O correio eletrônico é um serviço clássico da rede e provavelmente o mais popular. Sendo um serviço do tipo store-and-forward, ele possui alguns elementos importantes para o seu funcionamento. São eles:

    Sendmail

    O sendmail é um MTA de propósito geral que, quando utilizado sobre o TCP/IP, implementa o Simple Mail Transfer Protocol (SMTP). Entre suas capacidades destacamos também os mecanismos de alias, forward, inclusão e execução de processos remotos, além da capacidade de conversão de formatos de mensagens.

    Foi desenvolvido por Eric Allman da Universidade da California - Berkeley, de acordo com as RFC 822 (Internet Mail Format Protocol), RFC 821 (SMTP), RFC 1123 (Internet Host Requirements) e RFC 1425 (SMTP Service Extensions). O sistema é tão flexível que pode ser configurado com requisitos adicionais que superam os padrões especificados nas RFCs.

    O sendmail foi portado para diversas plataformas, dentre a quais citamos: AIX, ConvexOS, FreeBSD, HP-UX, IRIX, Linux, NetBSD, OSF/1, SOLARIS, SunOS, ULTRIX. A versão mais recente, onde foram corrigidos bugs clássicos de sendmail, pode ser encontrada em

    ftp://ftp.cs.berkeley.edu/pub/sendmail

    A versatilidade do sendmail torna-o vulnerável com relação à segurança. Portanto, é importante e recomendável configurá-lo corretamente, não apenas para o perfeito funcionamento do correio eletrônico, mas também como forma de precaução quanto a possíveis problemas de segurança.

    A configuração é bastante simples: o pacote contém vários arquivos *.mc que refletem as diversas características e opções do sistema. Com o m4 (macro processor), são gerados os arquivos de configuração *.cf. Há também vários patches das últimas versões, para administradores que preferem não compilar nem instalar todo o sistema novamente.

    Referências:

    FAQs:

    ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/sendmail-faq

    ou envie uma mensagem com conteúdo send usenet/news.answers/mail/sendmail-faq para

    mail-server@rtfm.mit.edu

    Newsgroups:

    news:comp.mail.sendmail

    RFCs:

  • RFC 821 - SMTP protocol
  • RFC 822 - Mail header format
  • RFC 974 - MX Routing
  • RFC 976 - UUCP mail format
  • RFC 1123 - Host requirements
  • RFC 1413 - Identification server
  • RFC 1341 - MIME: Multipurpose Internet Mail Extensions
  • RFC 1344 - Implications of MIME for Internet Mail Gateways
  • RFC 987 - Mapping between RFC 822 and X.400
  • RFC 1049 - Content-Type header field (extensão para RFC 822)
  • Repositório:

    ftp://ftp.cs.berkeley.edu/pub/sendmail

    POP

    O servidor POP, Post Office Protocol server, é um gerenciador de mailboxes que pode ser executado em uma variedade de Sistemas Unix, como NetBSD, SunOS, Solaris, AIX, etc.

    Através do POP, o correio eletrônico pode ser utilizado diretamente em equipamentos como PCs e Macintosh, executando nesses equipamentos programas "user agent"s (UA) como PMail e Eudora.

    Basicamente, a manutenção dos mailboxes é feita por um servidor que implementa o sistema de correio eletrônico (MTA) e o serviço POP. Através do POP, portanto, o mailbox é transferido para o PC ou MAC em questão, onde as mensagens, folders, etc., são manipulados localmente.

    Foi desenvolvido pela Universidade de Berkeley na Califórnia atendendo as especificações contidas nos RFC1081 e RFC1082.

    Referências:

    ftp://ftp.cr-df.rnp.br/pub/packages/mail/pop
    ftp://ftp.cc.berkeley.edu/pub/pop
    http://www.cis.ohio-sta

    4. Gerência de Redes

    A administração técnica de uma rede envolve uma série de atividades que, conjuntamente, visam o funcionamento adequado da mesma, e incluem:

    Para auxiliar o administrador da rede a desempenhar estas tarefas, existem ferramentas comerciais e de domínio público, que podem ser divididas em quatro categorias:

    A escolha sobre um ou outro produto depende basicamente do grau de gerenciamento, do tamanho da rede, das plataformas utilizadas e do capital disponível. Uma recomendação básica a ser feita na hora da escolha do produto de gerenciamento, e dos equipamentos gerenciados (roteadores, servidores de comunicação, etc.), é a existência do protocolo de gerência SNMP (Simple Network Management Protocol). O SNMP é considerado protocolo padrão para gerência de redes TCP/IP.

    Alguns dos produtos comerciais disponíveis no mercado para gerência de redes estão relacionados a seguir:

  • CABLETRON
  • http://www.ctron.com

    Spectrum 3.0

    Spectrum Portable Management Application (família de aplicações e módulos de gerência para dispositivos da Cabletron)

    Remote LANVIEW/Windows

  • CISCO
  • http://www.cisco.com

    CiscoWorks

    Workgroup Director

    NetScout

    Connectivity Baseliner

    Connectivity Solver

    Network Drawing Tool

  • 3COM
  • http://www.3com.com

    Transcend

  • DIGITAL
  • http://www.dec.com

    Polycenter

  • HP
  • http://www.hp.com

    HP-OpenView

    NetServer (gerenciador de servidores)

    HP Openview Operations Center

  • IBM
  • http://www.ibm.com

    Netview/6000

    TT/6000 (sistema de Trouble ticket)

    System Monitor

  • NEWBRIDGE
  • http://www.vivid.newbridge.com

    VIVID System Manager

    VIVID Router Server

  • NOVELL
  • http://www.novell.com

    Manage Wise

    NetWare Management System

    NetWare Management Agent

    NetWare Management Agent for Netview

    NetWare LANalyser Agent

    LANanlyse for Windows

    Netware Navigator

    Netware HUP Services

  • SUN
  • http://www.sun.com

    Solstice

    SNM for Solstice

    Netra System Management Server

  • SYNOPTICS (Bay Networks)
  • http://www.synoptics.com

    Optivity 6.0

  • TIVOLI
  • http://www.tivoli.com

    TME

    A seguir, são listados alguns softwares de domínio público, juntamente com os endereços dos repositórios onde podem ser encontrados. Na FAQ do SNMP é mantida também uma lista de pacotes para gerência distribuídos gratuitamente.

  • BTNG (Beholder- The Next Generation)
  • monitor de redes Ethernet

    ftp: dnpap.et.tudelft.nl:/pub/btng
  • HNMS (NAS Hierarchical Network Management System)
  • sistema de gerência de redes para monitorar o status e gerar estatísticas de tráfego para uma rede IP

    ftp: ftp.netcom.com:/pub/heyjude
  • Nocol (Network Operations Center OnLine)
  • monitor de redes TCP/IP

    ftp.jvnc.net:pub/jvncnet-packages/nocol

    Pacotes para desenvolvimento de ferramentas de gerência:

  • CMU Package
  • ftp: lancaster.andrew.cmu.edu
  • MIT Package
  • ftp: thyme.lcs.mit.edu:/pub/snmp
  • OSIMIS
  • http://www.cs.ucl.ac.uk/people/knight/osimis/osimis.htm
  • ISODE
  • ftp: gatekeeper.dec.com:/.3/net

    Repositório de MIBs Internet:

    ftp: venera.isi.edu:/mib

    Referências:

    http://www.slac.stanford.edu/netdoc/perf-rep.html

    (Monitoração e Análise de redes da Universidade de Stanford)

    http://smurfland.cit.buffalo.edu/NetMan/index.html

    (Informações gerais sobre gerência de redes)

    http://snmp.cs.utwente.nl

    (Informações gerais sobre gerência de redes).

    Apresentação de Padrões:

  • BRISA. Gerenciamento de Redes, Uma Abordagem de Sistemas Abertos. São Paulo, Makron Books, 1993
  • PERKINS, DAVID T. Understanding SNMP MIBS. Rev. 1.1.6, September, 1993
  • RFC1157 - CASE, J. et. al. A Simple Network Management Protocol (SNMP), 1990
  • RFC1156 - MCGLOGHRIE, K.; ROSE, M. Management Information Base for TCP/IP-based internets, 1990
  • RFC1065 - ROSE, M; MCGLOGHRIE, K. Structure and Identification of Management Information for TCP/IP-based internets, 1990
  • RFC1158 - ROSE, M. Management Information Base for Network Management of TCP/IP-based Internets: MIB-II, 1990
  • STALLINGS, WILLIAM. SNMP, SNMPv2, and CMIP: The Practical Guide to Network Management Standards. Addison-Wesley, 1993
  • Textos Introdutórios:

  • FEIT, SIDNIE. SNMP: A Guide to Network Management. McGraw-Hill, 1994.
  • FISHER, S. Dueling Protocols. BYTE, v.16, n.3, p.183-190, 1991.
  • RNP/DOC/0037 - ODA, C. S. Introdução a Gerência de Redes, 1994
  • RNP/DOC/0034 - ODA, C. S. Gerenciamento de Redes de Computadores - Noções Básicas
  • ROSE, M. The Simple Book- An Introduction to Management of TCP/IP-based Internet. 2nd edition. Englewood Cliffs, Prentice-Hall, 1991.
  • SCHNAIDT, P. Keep It Simple. Lan Magazine, p.82-92, julho 1990
  • Exemplos de Aplicação Prática:

  • HARNEDY, SEAN J. Total SNMP: Exploring the Simple Network Management Protocol. CBM Books, 1994
  • LEINWAND, ALLAN, AND FANG, KAREN. Network Management: A Practical Perspective. Addison-Wesley, 1993
  • MILLER, MARK E., P.E., Managing Internetworks with SNMP: The Definitive Guide to the Simple Network Management Protocol (SNMP) and SNMP version2. M&T Books, 1993
  • ROSE, MARSHALL T. AND MCCLOGHRIE, KEITH Z. How to Manage Your Network Using SNMP: The Network Management Practicum. Prentice-Hall, 1995 (published in 1994)