(3) Comentários

Por Rafael Leão, 24/11/2009 09:52

Proprietário Cisco, este recurso tem como objetivo agregar segmentos ethernet paralelos em uma única interface, possibilitando balanceamento de carga e redundância livre de loops. Esta interface é chamada de EtherChannel.

É muito útil em trunks entre switches ethernet, roteadores e servidores, ou em qualquer situação em que a demanda de tráfego seja muito alta. Outros benefícios do EtherChannel:

- Diminuição de tempo perdido com processos de convergência do spanning-tree, pois representam um único link lógico entre os switches, considerando o encaminhamento de frames;
- Para que a interface EtherChannel esteja "up", basta que apenas uma das portas associadas a esta também esteja;
- Se alguma das interfaces associadas ao EtherChannel falha, o tráfego continua a ser distribuído pelas interfaces que permanecem ativas, com mínima perda, e sem percepção por parte do usuário final.

A topologia abaixo representa aplicações típicas deste recurso.

Um Etherchannel suporta até 8 interfaces ethernet full-duplex, com velocidades de 100Mbps até 10Gbps.

Fast EtherChannel (FEC): interfaces ethernet de 100Mbps, com BW de até 1,6Gbps com 8 links de FastEthernet;
Gigabit EtherChannel (GEC): interfaces ethernet de 1Gbps, com BW de até 16Gpbs com 8 links de GigabitEthernet;
10-Gigabit EtherChannel (10GEC): interfaces ethernet de 10Gbps, com BW de até 160Gbps com 8 links de 10-GigabitEthernet.

Importante: apesar de 8 interfaces FastEthernet, carregadas ao máximo de tráfego, teoricamente poderem chegar a 800Mbps de throughput, o bundle não irá operar a esta velocidade.

PAgP

Port Aggregation Protocol é o protocolo que auxilia a negociação e estabelecimento do EtherChannel Cisco. Ele associa as interfaces físicas em grupos chamados “channel-groups”, e cada um desses formará uma interface chamada “port-channel”, que irá distribuir o tráfego entre elas.

As interfaces físicas devem estar em um dos 3 modos PAgP a seguir para operarem numa interface EtherChannel:

Auto: neste estado, a interface está configurada para aceitar qualquer pedido de formação do EtherChannel;
Desirable: a interface busca negociar com a outra ponta a formação EtherChannel;
On: a porta está configurada como parte do EtherChannel estaticamente, e não toma iniciativa de negociar.

Para que o EtherChannel por fim se estabeleça em ambas as pontas, o link entre os dispositivos conectados devem ter as seguintes combinações:

- Auto-desirable;
- Desirable-desirable;
- On-on.

Distribuição de Tráfego no EtherChannel

O tráfego não é necessariamente distribuído por igual entre os links do EtherChannel. Um algoritmo de hash é responsável por determinar a qual link determinado frame será encaminhado. Ele executa uma operação XOR (exclusive-OR) usando uma combinação dos bits mais baixos de endereços MAC ou IP de destino e origem, no qual o resultado determina o link de destino. Pode-se usar MAC de origem, MAC de destino, ou ambos, IP de origem, IP de destino ou ambos, ou portas TCP/UDP.

Por padrão, o método de balanceamento é IP de origem + IP de destino (src-dst-ip).

802.1Q e ISL em EtherChannels

Para que o EtherChannel se torne um trunk Dot1q ou ISL, todas as interfaces devem estar corretamente configuradas como trunk, com as mesmas permissões de VLAN e VLAN nativa. Uma vez que uma interface associada a um EtherChannel seja configurada como trunk, todas as demais terão a mesma configuração. Com relação a ser uma porta de acesso, todas as interfaces devem pertencer a mesma VLAN.

Restrições

A Cisco recomenda que as seguintes configurações sejam evitadas para que o EtherChannel opere sem causar erros:

- Não sejam configurados mais do que 48 EtherChannels em um switch;
- 802.1x não seja configurado nas portas do EtherChannels;
- Não configurar a interface EtherChannel como destino de um SPAN;
- Nao podem ser mixados em um EtherChannel portas com velocidades ou tipos de trunk diferentes.

IEEE 802.3ad – LACP

Padrão aberto que tem o mesmo objetivo do EtherChannel, e que usa o LACP (Link Aggregation Control Protocol) para configurar os links agregados, enquanto o EtherChannel Cisco usa o PAgP, conforme descrito acima.

Mais informações sobre LACP e PAgP.

Espero que tenha ajudado. Até breve!

(2) Comentários

Por Rafael Leão, 05/10/2009 18:50

O PAT – Port Address Translation, também conhecido como NAT Overload, permite que múltiplos usuários da LAN acessem a Internet, representados por um pequeno range de IP’s, ou até mesmo um único. Este recurso associa cada IP interno com uma porta TCP ou UDP junto ao IP inside global; estas portas permitem que as conexões de IP’s internos sejam identificadas, e tenham um fluxo bidirecional.

Neste cenário, a rede local 10.10.10.0/24, será representada pelo IP inside global de BrainRT – 200.20.20.1; 3 usuários acessarão o servidor remoto 199.19.9.1, via Telnet, SSh e HTTP.

Configuração de BrainRT:

!- Entrar no modo de configuração global
configure terminal
!- Configuração da interface OUTSIDE, que se conecta a Internet
interface FastEthernet 0/0
ip address 200.20.20.1 255.255.255.248
!- Apontando que por esta interface serão enviados os pacotes traduzidos
ip nat outside
no shutdown
exit
!- Configuração da interface INSIDE, onde está conectada a LAN
interface FastEthernet 0/1
ip address 10.10.10.254 255.255.255.0
!- Indicando ao router que neste interface há os IPs internos
ip nat inside
no shutdown
exit
!- Criando uma ACL que identifica os hosts que passarão pelo processo de NAT
access-list 1 permit 10.10.10.0 0.0.0.255
!- Associando a ACL e a interface global ao processo de NAT
ip nat inside source list 1 interface FastEthernet 0/0 overload

O seguinte comando deve ser enfatizado:

ip nat inside source list 1 interface FastEthernet 0/0 overload

O parâmetro ‘interface FastEthernet 0/0’, indica que o processo de NAT irá usar o IP desta interface como inside global, independente de qual seja; alternativamente, pode ser usado, em vez deste, um IP que será o inside global desejado, independente do que está configurado na interface outside. Outro ponto importante, é o parâmetro ‘overload’ ao final do comando; ele possibilita que os diversos endereços internos sejam representados pelo IP da interface FastEthernet 0/0, construindo uma representação um-para-vários. Observe os exemplos seguintes, após aplicada a configuração em BrainRT:

Tabela NAT, antes de qualquer acesso de hosts internos:

Tabela NAT após acesso SSh do host 10.10.10.100 ao servidor remoto:

Tabela NAT após acesso Telnet do host 10.10.10.1 ao servidor remoto:

Tabela NAT após acesso HTTP do host 10.10.10.200 ao servidor remoto:

Os contadores da tabela NAT poderão ainda conter 251 IP’s internos válidos, conforme configurado na ACL 1, e diversas conexões de cada um deles, para qualquer host acessível através da internet. Estes contadores podem ser zerados com o comando EXEC ‘clear ip nat translation *’, onde * representa todas as entradas. Qualquer dúvida, é só postar um comentário.

Espero que tenha ajudado. Até o próximo post!

(7) Comentários

Por Rafael Leão, 20/09/2009 02:11

No terceiro post sobre NAT, será mostrado um exemplo de configuração de NAT Dinâmico.

O ISP cederá à organização um pool com 6 endereços válidos: 200.30.30.1 a 200.30.30.6; e uma ACL padrão identificará o range em que se encontram os endereços locais que serão traduzidos: 10.10.10.0/24. Esta configuração será feita no roteador BrainRT.

Observação: a LAN da organização contém um range de 254 endereços locais, mas há somente 6 endereços válidos. Portanto somente os 6 primeiros a tentarem acessar a internet conseguirão, pois o roteador faz uma associação destes IP’s com os IP’s globais do pool, até que este se esgotem; daí em diante, nenhum outro host terá acesso, a menos que se use o parâmetro ‘overload’, que será explicado no próximo post.

Configuração de BrainRT:

!– Configurando a interface inside, onde se encontram
!– os endereços locais a serem traduzidos
interface FastEthernet0/0
ip address 10.10.10.254 255.255.255.0
ip nat inside
!– Configurando da interface outside, para onde serão enviados os
!– pacotes traduzidos
interface FastEthernet0/1
ip address 200.20.20.1 255.255.255.248
ip nat outside
!– Configurando o pool de endereços globais, cedidos pelo ISP,
!– que darão acesso para os hosts interno à internet
ip nat pool GLOBAL_POOL 200.30.30.1 200.30.30.6 netmask 255.255.255.248
!– Configurando a ACL que dirá ao router quais serão os IP’s locais
!– a passarem pelo processo de NAT
access-list 1 permit 10.10.10.0 0.0.0.255
!– E, por final, associando os endereços locais, identificados na ACL 1,
!– ao pool ‘GLOBAL_POOL’ criado anteriormente
ip nat inside source list 1 pool GLOBAL_POOL

Observe que, após aplicada a configuração, a tabela NAT de BrainRT ainda não contém nenhuma entrada, pois ainda não houve nenhuma tentativa de acesso:

BrainRT#show ip nat translations

BrainRT#

Agora, veja como estão as entradas da tabela NAT após acesso web do host 10.10.10.1, ao servidor remoto:

BrainRT#show ip nat translations
Pro Inside global         Inside local          Outside local         Outside global
tcp 200.30.30.1:2277      10.10.10.1:2277       199.19.9.1:80         199.19.9.1:80
tcp 200.30.30.1:2278      10.10.10.1:2278       199.19.9.1:80         199.19.9.1:80
tcp 200.30.30.1:2279      10.10.10.1:2279       199.19.9.1:80         199.19.9.1:80
tcp 200.30.30.1:2280      10.10.10.1:2280       199.19.9.1:80         199.19.9.1:80
tcp 200.30.30.1:2281      10.10.10.1:2281       199.19.9.1:80         199.19.9.1:80
— 200.30.30.1 10.10.10.1 —                   —
BrainRT#

E após um ping do host 10.10.10.80:

BrainRT#show ip nat translations
Pro Inside global         Inside local          Outside local         Outside global
— 200.30.30.1 10.10.10.1 —                   —
icmp 200.30.30.2:512      10.10.10.80:512       199.19.9.1:512        199.19.9.1:512
— 200.30.30.2 10.10.10.80 —                   —
BrainRT#

Em negrito, estão as entradas estáticas geradas, assim que o host interno acessa pela primeira vez um endereço da internet. Ela vai sendo preenchida até que se esgotem os endereços do pool, e neste ponto, como dito anteriormente, nenhum outro host interno poderá acessar a internet.

Um ponto interessante, é que o pool de endereços globais, não precisam estar na mesma subrede da interface pública (neste caso, 200.20.20.1); a responsabilidade de roteamento para alcançar estes endereços é feita pelo ISP.

Dica: com o comando ‘clear ip nat translations *’, em modo EXEC, todas as entradas na tabela de NAT são zeradas.

Qualquer dúvida, estamos à disposição. No próximo post, será explicado o PAT. Fique atento!

Espero que tenha ajudado. Até breve!

Só um comentário

Por Rafael Leão, 11/09/2009 08:00

No segundo post sobre NAT, será mostrada a configuração do NAT estático, onde o usuário por trás de BrainRT, irá acessar o servidor remoto 199.19.9.1. Neste exemplo, o host interno 10.10.10.1 será representado globalmente pelo IP 200.20.20.3. Este tipo de NAT é muito útil quando um host necessita ser acessado de fora da organização. Esta configuração gera uma entrada permanente na tabela NAT, que associa o IP interno 10.10.10.1 ao IP global 200.20.20.3.

Configuração:

Abaixo, está a configuração de BrainRT:

Agora vamos aos testes!

1º) Vejamos a tabela NAT em BrainRT após a configuração; observe a associação estática entre os IP’s ‘inside local’ e ‘inside global’:

2º) Agora, após um ping ao servidor remoto:

3º) Adicionalmente, vejamos após o acesso telnet ao servidor:

4º) Agora, com acesso SSh:

Como podemos observar neste exemplo, um IP interno foi associado estaticamente a um IP dentro de um range válido, na mesma subrede da interface outside de BrainRT.

Dúvidas, verifique o primeiro post sobre NAT. Logo mais a parte 3! =D

Espero que tenha ajudado. Até breve!

Seja o primeiro a comentar

Por Rafael Leão, 25/08/2009 10:19

Sabemos que as comunicações remotas pela internet existem há mais de 50 anos. Porém, a World Wide Web ainda é nova: somente 20 anos!

No começo, o "www" era restrita ao meio acadêmico, mas hoje há mais de 2 bilhões de usuários, 1 trilhão de URL’s…
Ocorreram muitas mudanças, e recursos talvez inimagináveis antigamente, hoje são comuns e facilmente encontrados em páginas da web.

O site da Cisco, em 1996, pode dar-nos uma idéia de como eram as páginas nesta época:

Para os usuários mais novos, um conteúdo curioso… para os veteranos, a lembrança de como era no começo: o Wayback Machine nos leva ao passado, e conta um pouco da história da Web.

Até breve!