Agregaçao de links Ethernet usando Etherchannel (I)

As redes Ethernet sempre possuiram dois problemas:

1 – Debito binário ponto a ponto constante: Isso é uma verdade, pois os padrões Ethernet (10 Base-T, 100Base-T por exemplo) cresceram sempre numa magnitude pouco variável. Isto não representa um problema quando estamos tratando de ligações na camada de acesso. Mas se estamos falando por exemplo de ligações na camada de distribuição isso representa um problema sim. Pense na época em que o padrão GigabitEthernet (1000Base-X, 1000Base-T, 1000Base-CX) não havia sido criado. Mesmo se termos em conta que o padrão 100Base-FX por já permitia transmissao por meio de fibra óptica em ligações ethernet isso apenas garantia qualidade na recepção, menos erros durante a transmissao, diminuição da atenuação do sinal e menos bits perdidos.  Não garantia aumento do débito binário.

2 – Ponto de falha único: É muito normal na camada de acesso ter uma ligação desfeita. Isso na camada de distribuição ou de Core seria um autentico desastre para a eficiência das comunicações que se exige constante e infalível, além de constituir um bom motivo para te fazerem uma fita la na empresa.

Para dirimir estes problemas foram criadas tecnologias e protocolos de agregação de links. Confesso ter ficado maravilhado quando tomei conhecimento delas. Uma destas tecnologias é a tecnologia Etherchannel da Cisco. Basicamente o que ela faz é agregar o debito binário dum conjunto de ligações físicas (de 2 até 8 ligações) entre dois comutadores e criar um canal lógico entre elas cujo débito binário é a soma de todos os débitos dos canais físicos conectados ponto a ponto.
Isto quer dizer que se você tiver 8 portas FastEthernet você terá 8x100Mbps = 800Mbps de débito binário. Se forem 8 portas GigabitEthernet (GbE) você terá 8×10^9bps = 8Gbps. Se forem 8 portas 10GbE você terá 80Gbps de débito binário.

Exemplo dum ambiente onde se pode aplicar a tecnologia EtherChannel

 

No exemplo acima tempos depois da camada de acesso, a camada de distribuição onde podemos localizar dois comutadores Catalyst 3550 e 8500/6000 ou 4000. Note a existência de quatro ligações GbE. Consegue-se um débito de 4×10^9=4Gbps. Esse é o débito para CADA UMA das interfaces conectadas. Lembre-se que este débito sem a existência do Etherchannel era de 1 Gbps para cada uma das interfaces.

Isso representa um ganho e tanto em termos de débito binário, mas também em termos de redundância. Mesmo se um link perder a conexão os outros links ainda continuarão a transmitir (mesmo significando isso uma baixa em termos de débito binario).

No próximo artigo veremos um exemplo prático de configuração de Etherchannel.

Voce conhece as macros Auto SmartPort do Catalyst 3750?

Basicamente esta é uma função que configura uma interface do comutador Catalyst da serie 3750 consoante o tipo de dispositivo a ela conectada. Por exemplo se você ligar a uma de suas interfaces um telefone VoIP ele automaticamente identifica que um telefone VoIP foi conectado a ele. O Catalyst 3750 consegue fazer isso por trocas de mensagens CDP com o dispositivo conectado a sua interface. No caso de ser um telefone VoIP ele aplica automaticamente uma macro, a macro CISCO_PHONE_AUTO_SMARTPORT.

Isso é duma utilidade que vocês não imaginam. No caso da macro acima ela imediatamente configura a interface para suporte a Qualidade de Serviço, segurança e atribui a mesma a uma VLAN de voz (que pode ser configurada para corresponder a uma VLAN de voz que você já tenha configurado). Se termos em conta que as vezes as interfaces podem se tornar escassas, esta também é uma boa solução para este problema.

Mais informações, bem como um exemplo de configuração podem ser encontrados aqui.

Guia da Cisco para segurança de dispositivos

A Cisco pensa que as funções de um dispositivo de rede podem ser categorizadas dentro de 3 planos de rede: Plano de gestão, controlo e dados.

  • Plano de gestão — O plano de gestão gere o tráfego que é enviado a um dispositivo Cisco e é baseado em aplicações e protocolos tal como SSH e SNMP.
  • Plano de controlo — O plano de controlo processa o tráfego prioritário e necessário para manter a infraestrutura da rede. Este plano consiste de protocolos EGPs e IGPs.
  • Plano de dados — O plano de dados apenas se ocupa em encaminhar tráfego através dum dispositivo de rede. Tráfego que vem de fora não pertence a seu escopo.

Tendo em contra estes planos a Cisco desenvolveu um guia que traduz importantes recomendações de segurança para os dispositivos de rede. Naturalmente existem tópicos mais avançados, mas este é claramente um ponto de partida.

5 passos para melhorar sua conectividade Wireless

Este post interessante da Cisco dá cinco dicas úteis que podem ajudar a melhorar a conectividade de sua rede Wireless sem ter em conta que espécie de dispositivo ela está servindo. Como sabem hoje em dia, não temos apenas computadores e laptops, mas também tablets, smartphones consolas de jogos etc. Então não é uma boa ideia tentar controlar eles de modo individual de modo a tirar melhor proveito da rede, mas sim arquitectar uma rede que suporte todos eles.

OPNet: O verdadeiro simulador para engenheiros de Telecomunicaçoes

Enquanto andei na universidade, tive a oportunidade de ser confrontado com o desafio de dominar diversos simuladores. Os simuladores são programas computadorizados (software) que servem para simular uma situação que aconteceria da mesma forma no mundo real. Por exemplo na cadeira de Teoria dos Circuitos Eléctricos usei simuladores para medir diversos parâmetros da corrente eléctrica, como voltagem, tensão, potencia, impedância, etc, ou testar in loco o funcionamento de circuitos próprios como Thevenin.

Em redes de computadores era muito usual o Packet Tracer da Cisco. Trata-se dum simulador com características próprias. Como a Cisco fabrica equipamentos de redes tais como encaminhadores (routers) e comutadores (switchs) eles resolveram se concentrar nestes equipamentos, por isso o Packet serve mais para quem quer aprender a trabalhar com equipamentos e protocolos que a Cisco utiliza em redes de baixa a media escala.
O problema é que o engenheiro de Telecomunicações é essencialmente alguém que se pode também especializar em transmissao, e quando falamos de transmissao, estamos falando de transmissao em toda gama de frequências, utilizando todo tipo de emissores e receptores. Portanto isso inclui, desde transmissao por meio de feixes hertzianos, feixes de luz ou mesmo batuque e fumo (se você tiver uma maquina do tempo e assistir Mr Bean).

Voltando a falar a serio. O Packet Tracer, simplesmente se marimba para esse facto. É engraçado um engenheiro projectar uma ligação ponto-a-ponto e dizer apenas que a ligação é serial. Ora, isto não basta. Na basta configurar um clock rate qualquer no encaminhador sem consultar o engenheiro de Transmissão. A transmissao é mais importante que o processamento, porque sem um meio de transmissao fiável, não existe processamento que seja útil.

Hoje em dia virou moda qualquer um achar que pode projectar um meio de transmissao. É verdade que você pode até ter recepção de sinal, mas pode ter certeza que a cobertura e qualidade podiam ser melhores. É necessário projectar com clareza antes de sair por aí montando antenas e esticando cabos de fibra óptica.

Na minha monografia para a defesa do titulo de engenharia em Telecomunicações, foi-me colocado o desafio de projectar um sistema de Voz por IP num ambiente Multi-Serviços. Utilizei o simulador OPNet (utilizado pela NASA, FBI, Harvard University, Cisco, BT e milhares de universidades e estudantes de nível superior) para simular diversos cenários da rede Multi- Serviços projectada em que o objectivo era conseguir um atraso nas chamadas de voz que estivessem dentro dos padrões internacionais.
Sendo assim, estes cenários incluíam por exemplo, o caso em que um técnico inexperiente substituía numa interface dum Core router um cabo de débito STM-x e substituía por um de débito binário menor (tal como um DSx). Por fim um cenário em que todas as interfaces estavam padronizadas com débitos recomendados pela industria.

O ambiente de comunicação Multi- Serviços é este:


Tecnologias e padrões de comunicação usados nas interfaces dos quatro cenários:

Nome do Cenário/Interfaces Borda_Este àCore_2 Borda_Oeste àCore_1 Core_1 àCore_2 Codec Técnica de QoS
Cenário I PPP SONET/OC48
(STM-16)
DS3 DS1 G.711 Nenhuma
Cenário II PPP SONET/OC48
(STM-16)
DS3 DS1 G.729 com VAD Nenhuma
Cenário III DS1 DS1 DS1 G.729 com VAD LLQ
Cenário IV PPP
SONET/OC48
(STM-16)
PPP SONET/OC 48       (STM-16) PPP SONET/OC48
(STM-16)
G.729 com VAD LLQ

Quem entende um bocado de SDH e QoS não deve ter dificuldade de perceber o que se pretende na tabela acima.  Mas realmente não é difícil de de entender. Compare os cenários I e III. Uma interface óptica OC48 ou STM-16 tem 2.5Gbps de débito binário. Por seu lado um DS1 ou T1 (24 DS0 + 1 bit de framing, cada a 64Kbps) tem 1,544Mbps. Claramente na óptica de alguém que não domina conceitos de transmissao o cenário I teria melhor capacidade que o cenário III de enviar os dados do processamento, afinal as suas interfaces possuem um debito mais alto. Isto também eu pensava, mas os resultados obtidos em simulação com o OPNet mostraram a verdade:

Este é o resultado duma simulação realizada numa chamada de voz entre qualquer dispositivo de voz duma das filiais. A chamada passa pelo provedor Multi-Serviços e o atraso fim-a-fim (o tempo que leva de um extremo a outro) é medida nos quatro cenários. Os resultados são apresentados no cenário acima. No eixo das ordenadas temos o atraso medido em segundos e no eixo das abcissas o tempo de simulação.

O cenário III não tem esse resultado a toa. Isso tem que ver com o facto de ela ter todas as suas interfaces padronizadas (todas DS1) ao contrario do cenário I onde a falta de padronização acaba por criar gargalos que na linguagem rodoviária conhecemos como engarrafamentos.
No cenário IV a aplicação duma técnica de qualidade de serviço como a LLQ (Low Latency Queue) ordena a saída dos pacotes e descarta os pacotes que não sejam de voz concedendo prioridade a voz, ou seja é um agente regulador de transito para os pacotes de voz.

Como puderam reparar, tudo isso só é possível quando está um engenheiro de transmissao na empresa. De nada adianta sair por aí criando ligações VoIP entre sedes e filiais sem ter em conta factores como atraso, variação de atraso, descarte de pacotes etc. Você pode aumentar muito débito, os resultados mostram que é inútil, não funcionará, a rede terá sempre muito atraso e as chamadas não terão qualidade. O mesmo se aplica ao vídeo como no caso da tecnologia IPTv.

Olho hoje para o mercado e observo um desprezo total aos engenheiros de telecomunicações. Isso é grave, as empresas deveriam repensar melhor a sua estratégia de melhoria dos serviços, e isto passa por contratar mais engenheiros de transmissao.

Encaminhamento de Broadcast de VLAN’s a servidor DHCP por detrás de roteador usando ip helper-address

Visualize o cenário abaixo:

As VLANs necessitam de obter endereços pelo servidor DHCP

Este é um cenário muito comum, em algumas redes. O roteador serve de ponte de comunicação entre as VLAN 10 (IT) e 20 (FINANCE). O que as vezes é problemático é ter o servidor DHCP ‘atrás’ do roteador, ainda mais numa sub-rede que não pertence a qualquer uma das VLAN. Isso representa um problema porque sabemos bem como funciona o processo de obtenção de endereços IP pelo hosts em suma, seria impossível esses hosts se beneficiarem dos serviços DHCP porque o roteador não encaminha pedidos de Broadcast.

Alguns administradores evitam colocar roteadores a frente dos hosts. Outros situam servidores DHCP em sub-redes dos dos hosts. Bom, estas não são boas soluções, visto que algumas redes exigem mesmo cenários como o acima ou mesmo mais complexos, com muitos mais roteadores.

Nestes casos a Cisco providencia o comando de configuração de interface ip helper-address [endereço_do_servidor_dhcp]. Trata-se dum útil comando que permite ao administrador indicar a uma interface (a que recebe o broadcast) que ela pode encaminhar um pedido de broadcast dum host.

No nosso exemplo acima, como estamos usando um cenário de implementação de VLAN’s Router-On-A-Stick, então este comando necessita de ser aplicado nas sub-interfaces fa0/0.10 e fa0/0.20 pertencentes a interfaces fa0/0 que esta ligada directamente ao comutador (Switch0).

Deste modo o servidor DHCP consegue atender aos pedidos de quaisquer dispositivo que esteja ligado as VLAN 10 ou VLAN 20.

Comutador Switch0:

Switch0#sh run

interface FastEthernet0/1
switchport access vlan 10
switchport mode access

interface FastEthernet0/2
switchport access vlan 20
switchport mode access

interface FastEthernet0/3
switchport mode trunk

Encaminhador SNNANGOLA (Router0):

SNNANGOLA#sh run

hostname SNNANGOLA

interface FastEthernet0/0
no ip address
duplex auto
speed auto

interface FastEthernet0/0.10
encapsulation dot1Q 10
ip address 172.16.10.1 255.255.255.0
ip helper-address 172.16.30.2

interface FastEthernet0/0.20
encapsulation dot1Q 20
ip address 172.16.20.1 255.255.255.0
ip helper-address 172.16.30.2

interface FastEthernet0/1
ip address 172.16.30.1 255.255.255.0
duplex auto
speed auto