Forum on Cisco Redes

EtherChannel – Configuração – Parte 2

Thu, 17 Nov 2016 00:00:00 +0000

Olá Pessoal,

Como vimos anteriormente sobre os padrões que temos para o etherchannel, nesse post vou trazer uma topologia inicial, bem como alguns outputs para demostrar o estado de cada interface e suas caracteristicas. Vale lembrar que nesse primeiro momento, iremos fazer o etherchannel em Layer 2, e com o decorrer dos posts vou citar as configurações e alterações que precisamos fazer para trabalhar em Layer 3.

Segue nossa topologia para analise:

Nesse cenario o que vamos implementar seria:

SW1 = todas as portas habilitas para LACP em modo active e passive
SW2 = portas definidas para LACP em modo active e portas definidas para PAgP em modo desirable
SW3 = portas definidas para LACP em modo active e portas definidas para PAgP em modo auto

Com isso segue as configurações abaixo:

Desta forma estou apresentado as configurações como explicado em nossa tabela do post anterior. Assim podemos levantar as validações após as configurações executadas e garantir nosso ” bundle ” de conexão física.

Status sobre a negociação das portas e o protocolo que foi negociado entre suas respectivas portas.
Legenda para a interpretação de nosso log, demonstrando que estamos em Layer 2 em uso.

No grupo 3 temos a negociação em PAgP com o uso em Layer 2 e portas ativas.

Para que possamos validar a troca de pacotes que estão acontecendo entre as pontas remotas, gostaria deixar dois exemplos capturados no Wireshark para vocês avaliarem os campos utilizados para definir as configurações exercidas em cada equipamento. Neste exemplo observamos as FLAGS do inicializador e do receptor dessas informações.

Neste exemplo temos a função do PAgP sendo trocada entre seus vizinhos.

Espero que vocês tenham gostado e nos aguarde com mais detalhes sobre o etherchannel.

Abs,
Rodrigo

SLACK – Forum

Wed, 27 Apr 2016 00:00:00 +0000

Olá Pessoal,

Anteriormente nos estavamos utilizando nosso Forum atraves do phpbb3, entretanto como vocês viram em meu post anterior tive alguns problemas e como havia trazido essa nova ferramenta já anunciada em nossa fan page, gostaria novamente agora de mencionar em nosso BLOG sobre o SLACK.

A idéia é utilizar ela para que possamos discutir juntos, assim sendo como um grupo por sala, onde todos podem ir acompanhando os debates e conforme a necessidade de assuntos vou criando novas salas para segmentarmos o conteúdo.

Essa ferramenta é possivel utilizar também nos aparelhos móveis ( Android e iOS ), sendo assim podemos atender dentro das necessidades de mobilidade para acesso e discussão.

Segue uma tela via desktop e via Android:

Para acessar a ferramenta acesse através do link SLACK ou através de nosso widget.

Abs,
Rodrigo

Cisco Packet Tracer Mobile

Sat, 16 Aug 2014 00:00:00 +0000

Olá Pessoal,

Gostaria de notificar que a Cisco liberou o Packet Tracer Mobile, na qual até o presente momento temos apenas para a plataforma Android, acredito que logo em seguida eles já liberem para iOS.

Nessa primeira versão já teremos muitas das funções que já existe no Packet Tracer 6.1 ( Student Version ) e também podemos executar o .pkt

Segue uma tela abaixo dessa versão:

Acredito que agora temos mais uma facilidade para treinar nossos laboratórios e gerenciar mais o tempo para estudar a parte prática do CCNA 🙂 . Segue o link para fazer o download na play store.

Let`s go 😉

Abs,
Rodrigo

Fórum Operacional!!!

Sun, 23 Dec 2012 00:00:00 +0000

Olá Pessoal,

Gostaria de notificar que nosso fórum está operacional e aberto as discussões para os diversos tópicos criados. Você pode acessar-lo através do menu superior ” Forum “ ou através do link direto www.ciscoredes.com.br/forum .

Veja e confira abaixo como esta o visual:

Lembrando-se que para os usuários que já eram participantes e tinham usuários registrados em nosso BLOG terá que executar alguns processos para permanecer com o mesmo usuário, porém terá que sincronizar as duas bases de dados com o mesmo usuário / senha.

Esse processo pode ser visualizados através de nosso post.

Entre e participe desse novo recurso

Abs,
Rodrigo

MTU – Gera lentidão, será?

Mon, 27 Feb 2012 00:00:00 +0000

Olá Pessoal,

Nós já havíamos comentado sobre o pacote jumbro frame em um post anterior e como existem conceitos e configurações relacionados a este tópico, resolvi trazer um laboratório prático para demonstrar o funcionamento desse famoso MTU.

Segue abaixo a topologia executada no GNS3. Neste laboratório estou utilizando o Cisco 2691 em conjunto com o IOS: c2691-advsecurityk9-mz.124-15.T14.bin. Para a conectividade serial o hardware adicionado foi a WIC-2T. Os arquivos do GNS3 podem ser obtidos na nossa seção arquivos.

Nesse laboratório iremos mostrar como a mudança de um parâmetro, em algum ponto da rede, ou seja, na conexão entre a origem e o destino podem afetar a transmissão de pacotes através da Internet ou dentro de sua rede interna.

Neste exemplo iremos fazer a alteração em um parâmetro, entre a conectividade Ethernet do PE1 com o roteador de BackBone. Lembrando-se, que quando esses parâmetros são alterados na rede para habilitar um pacote jumbro frame, por exemplo, todo o caminho que irá encaminhar esse pacote deve aceitar a mesma definição para o MTU.

Para efetuar o teste de conectividade entre os dois pontos, foi executado um ping da máquina ( 192.168.3.10 ) e do roteador CE1 para o roteador CE2 ( loopback – 192.168.5.1). Nesse teste a única forma de fazer com que o pacote, não seja fragmentado, seria através de um parâmetro que chamamos de DF-BIT. Esse parâmetro podemos habilitar normalmente através da CLI do roteador, ou através do DOS de seu computador.

No primeiro teste foi executado o ping através desse comando:

CE1#ping 192.168.5.1 size 1401 df-bit

Type escape sequence to abort.
Sending 5, 1401-byte ICMP Echos to 192.168.5.1, timeout is 2 seconds:
Packet sent with the DF bit set
M.M.M
Success rate is 0 percent (0/5)

Logo abaixo vocês podem observar o status capturado no WireShark, para qual apresenta o “request” do ping, com a flag “df” habilitada.

Devido ao tamanho do pacote ser maior que o permitido pelo MTU, recebemos uma mensagem de “unreachable”, ou seja, o pacote não foi transmitido devido a flag DF-BIT habilitada.

Nesse outro teste envio um pacote de 1500bytes, sem nenhuma marcação do df-bit.

CE1#ping 192.168.5.1 size 1500

Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 192.168.5.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 212/345/412 ms

Nesse teste é colocado 1400bytes, porém com o parâmetro df-bit habilitado.

Para um teste final, fizemos um ping com pacote de 8192bytes, liberando a fragmentação entre a origem e destino.

Essa configuração executada na interface Ethernet foi colocada como teste.

interface FastEthernet0/0
ip address 10.10.1.5 255.255.255.252
ip mtu 1400
duplex auto
speed auto

Desta forma, podemos demonstrar que temos influências no meio de transmissão, quando trabalhamos com um pacote Ethernet e com isso podemos responder a pergunta colocada no título de nosso post.

Espero que vocês tenham gostado e aguardo comentários 🙂 . Se vocês acharem melhor, eu posso fazer uma vídeo aula para demonstrar todos os testes online. Fico no aguardo.

Abs,
Rodrigo

Pacote Jumbo Frame – Ethernet

Mon, 07 Nov 2011 00:00:00 +0000

Olá caros,

Hoje iremos tratar de um assunto que escutamos no nosso dia-a-dia, e que em determinados ambientes temos uma grande utilização para esse meio de comunicação ” Metro-Ethernet “.

Neste post vamos trazer informações referenciando-se ao pacote JUMBO FRAME. Vocês poderiam perguntar, porque esse nome?

Na verdade esse nome foi dado, devido a capacidade de informações que podemos inserir dentro do mesmo pacote, para conseguir atravessar o meio sem efetuar fragmentação no pacote. Mas vamos entender melhor esse método, pois dependendo do ambiente isso também não traz benefícios.

O limite de 1500 bytes para o conteúdo dos frames foi criado originalmente como parte das especificações do padrão 10BASE-5, o padrão Ethernet original, de 10 megabits. A idéia era que frames muito grandes agravariam o problema das colisões, permitindo que uma única estação utilizasse o cabo durante um tempo muito longo. Além disso, frames maiores demorariam mais tempo para serem retransmitidos em caso de corrupção do conteúdo, de forma que os 1500 bytes foram aceitos como o melhor custo-benefício.

Dentro das características do padrão ethernet, bem como para o padrão coaxial, segue uma tabela para uma demonstração dessas especificações. Mais detalhes podem ser obtidos através desse link:

O problema é que, de lá pra cá muita muita coisa mudou. O cabeamento evoluiu, a velocidade das redes aumentaram para 100, 1000 e agora para 10000 megabits (1000 vezes a velocidade do padrão original) e, com a substituição dos hubs por switches, as colisões de pacotes deixaram de ser um problema.

Em uma rede de 10 megabits, é possível transmitir 819 frames com 1500 bytes de dados por segundo (lembre-se de que cada frame precisa de 26 bytes adicionais, que incluem os endereços, códigos de CRC e os demais componentes), o que faz com que cada frame demore 1221 nanosegundos para ser transmitido. Em uma rede Gigabit Ethernet, onde a velocidade é 100 vezes maior, o tempo de transmissão de cada frame cai para apenas 12 nanosegundos.

Como o processo de verificação do conteúdo dos frames consome processamento, trabalho que aumenta proporcionalmente conforme aumenta o volume de frames transmitidos, a velocidade das transferências acaba sendo limitada não apenas pelo desempenho das placas, mas também pelo desempenho do processador principal.

Nas redes de 10 e 100 megabits isso não chegava a ser um grande problema, mas a popularização das redes Gigabit Ethernet trouxe o assunto para ser avaliado. Percebendo a possibilidade de melhorarem o desempenho de seus produtos, muitos fabricantes passaram a desenvolver extensões proprietárias, que permitem utilizar frames maiores e assim reduzir o overhead. Estes frames gigantes são os chamados de jumbo frames.

Inicialmente, diferentes padrões eram incompatíveis, mas, com o passar do tempo, os fabricantes concordaram em padronizar o tamanho em 9000 bytes, o que permitiu a interoperabilidade entre produtos de diferentes fabricantes. Em alguns modelos de equipamentos da Cisco, podemos configurar esse valor para 9126 bytes.

A idéia é que o processamento necessário para verificar o CRC de um frame de 1500 bytes de dados não é muito diferente do para verificar um de 9000 bytes, de forma que o uso do processador decai brutalmente com a redução no número de frames transmitidos. Outra vantagem é que recheando cada frame com mais dados, a perda causada pelos 26 bytes adicionais decai proporcionalmente, melhorando o desempenho da rede.

O grande problema dos jumbo frames é que eles não fazem parte dos padrões Ethernet. Como aumentar o tamanho dos frames quebra a compatibilidade com os padrões de rede anteriores, o que é uma das grandes prioridades do IEEE.

Pensando dessa forma, existem alguns métodos para fazer configurações dentro do meio Ethernet, para que possamos encaminhar esses pacotes de 9000bytes dentro da rede. Olhando para os modelos de equipamentos da Cisco, temos diferenças relacionadas as linhas de configuração para cada plataforma ( hardware ). Vamos mencionar alguns modelos, porém podemos consultar a documentação oferecida pela Cisco.

6000 / 6500 / 7600 – Devemos verificar o hardware instalado nesse chassi, para verificar compatibilidade

7609(config)#int gigabitEthernet 1/1
7609(config-if)#mtu ?
<1500-9216> MTU size in bytes

4000 / 4500 – Verificar compatibilidade de hardware, sempre observando qual modelo de supervisora esta sendo utilizado

sup3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
sup3(config)#interface gigabitEthernet 1/1
sup3(config-if)#mtu ?
<1500-9198> MTU size in bytes

3750 / 3560 – Temos diferenças para a disponibilização entre as portas 10/100 e para as portas 1000.

3750(config)# system mtu 1546
3750(config)# exit
3750# reload

3750(config)# system mtu jumbo 9000
3750(config)# exit
3750# reload

2960 – Temos diferenças para a disponibilização nas portas 10/100 e 1000

2960(config)# system mtu 1998
2960(config)# exit
2960# reload

2960(config)# system mtu jumbo 9000
2960(config)# exit
2960# reload

Existem outros modelos referenciando-se aos switches Cisco, porém isso pode ser consultado através desse link.

Como podemos observar esses parâmetros estão designados as conectividades ethernet, ou seja, no momento que estamos trafegando para ambientes WAN que utilizamos outras tecnologias, esse tamanho de pacote vai ser segmentado conforme a especificação daquela interface, para qual vai ter um circuito E1, E3, OC3 e etc.

Podemos mencionar alguns ítens que são necessários para avaliação de habilitar jumbo frame na rede:

Placas e switches GigabiEthernet suportam a utilização de jumbo frame, portanto temos que avaliar os equipamentos instalados na rede.
Avaliar a comunicação fim a fim, pois se determinados meio de comunicação não obtiver essa configuração, você irá segmentar os pacotes, podendo até piorar a performance da rede.
Jumbo frames traz benefícios na transferência de grandes arquivos, pois se a rede utiliza muito streaming, pequenos arquivos você não irá perceber tanta diferença.

Esse detalhe é apenas uma informação que pode ser alterada dentro das especificações ethernet, para qual chamamos de MTU ( Maximum Transmission Unit ). Para o próximo post vou mencionar sobre uma outra particularidade que chamamos de MSS.

Espero que aproveitem as informações e aguardo comentários 😉

Abs,
Rodrigo

Fontes:
https://supportforums.cisco.com/docs/DOC-2013
http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml