EIGRP on Cisco Redes

EIGRP – Configuração Load Balance

Tue, 29 Nov 2016 00:00:00 +0000

Olá Pessoal,

Acredito que todos já tenham escutado em algum momento que precisamos melhorar a performance da rede, porém não temos ” $$$ ” para fazer upgrades em circuitos, equipamentos, etc.

Partindo desse principio, podemos pensar em fazer algo que seja rapido e pratico, portanto gostaria de compartilhar com vocês uma dica para habilitar o balanceamento por custos desiguais utilizando o EIGRP.

Para nossa analise gostaria de compartilhar essa topologia:

A logica de raciocinio será baseado entre o Router E para a Network X. Os valores utilizados aqui são inteiros para facilitar em nossa analise, tendo assim podemos considerar:

E-B-A com metrica de 30
E-C-A com metrica de 20
E-D-A com metrica de 45

Olhando os valores teríamos apenas o caminho ECA como disponível na tabela de roteamento para alcançar a rede X, ou seja, o ” sucessor “, porém gostaríamos de balancear. Para isso devemos aplicar essa configuração dentro do processo de EGIRP:

router eigrp 1

variance 2

Esta configuração aumenta a métrica mínima para 40 ( 2 * 20 = 40 ). O EIGRP inclui todas as rotas que têm uma métrica menor ou igual a 40 e que satisfazem a FC ( feasible condition ). EIGRP agora usa dois caminhos para chegar à rede X, E-C-A e E-B-A, porque ambos os caminhos têm uma métrica de menos de 40. O EIGRP não usa o caminho E-D-A porque esse caminho tem uma métrica de 45, que não é menor que o valor da métrica mínima de 40, devido à configuração de variância. Além disso, RD ( report distance ) do vizinho D é 25, que é maior do que FD ( feasible distance ) de 20 a C. Isso significa que, mesmo se a variância for definida como 3, o caminho E-D-A não é selecionado para o balanceamento de carga porque o roteador D não é um sucessor viável ( feasible sucessor ).

Espero que tenham gostado!!!

Abs,
Rodrigo

Fonte: http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13677-19.html

Aula 7 – Sumarização DMVPN – Phase 2

Mon, 15 Aug 2016 00:00:00 +0000

Olá Pessoal,

Gostaria de compartilhar mais uma video que disponibilizei em nosso canal do Youtube. Conforme já havia notificado nas aulas anteriores, nesse laboratório explico sobre sumarização em Phase 2 do DMVPN com utilização do EIGRP.

Neste exemplo iremos verificar que a partir do momento de implementar a rota default, voltaríamos a trabalhar no conceito de phase 1. Vale a pena conferir!!!!

Abs,
Rodrigo

Aula 6 – DMVPN – Sumarização

Mon, 08 Aug 2016 00:00:00 +0000

Olá Pessoal,

Neste exemplo iremos perceber a total funcionalidade do protocolo NHRP. Vale a pena conferir!!!!

Espero que vocês tenham gostado e deixe seus comentários ( positivos ou negativos ).

Abs,
Rodrigo

Video Aula – DMVPN

Fri, 10 Jun 2016 00:00:00 +0000

Olá Pessoal,

Gostaria de notificar sobre nossa playlist explicando sobre a solução DMVPN da Cisco. Nessas aulas explico sobre as 3 fases do DMVPN.

Posteriomente depois vou começar a detalhar mais um pouco sobre as funcionalidades que podemos executar no protocolo de roteamento ( IGP )

Abs,
Rodrigo

MSS – Maximum Segment Size

Thu, 29 Mar 2012 00:00:00 +0000

Olá Caros,

Como havia prometido vamos comentar um pouco sobre o termo mencionado acima. Portanto, o que significa MSS? 😕

MSS está relacionado com o tamanho máximo do datagrama IP, ou seja, ele tem relação com as conexões TCP e UDP. Para isso temos algumas suposições feitas anteriormente de que o tamanho padrão do datagrama tem alguns valores incoerentes. Esse pensamento foi absorvido por volta de 1983:

A origem não pode enviar datagrama maiores do que 576 octetos, a menos que eles tenham um conhecimento específico de que o destino está preparado para aceitar datagrama maiores.

Para solucionar esse conceito, podemos chamar de ambiguidade, o TCP MSS foi definido com a seguinte regra:

O tamanho do TCP MSS é o máximo tamanho do datagrama IP menos 40

O máximo tamanho do datagrama IP é 576
O TCP MSS é 536

A definição para o MSS esta detalhado através da RFC 879. O TCP provê uma opção que pode ser usada no momento que a conexão é estabelecida ( somente ), no qual indica que tamanho máximo no segmento TCP pode ser aceito naquela conexão. O MSS é enviado da origem para o destino e pode dizer ” Eu posso aceitar no segmento TCP até um tamanho X “. Esse tamanho X pode ser maior ou menor do que o padrão, e o MSS pode ser usado completamente independente de cada fluxo de direção do trafego.

Um ponto importante é que o MSS não conta o cabeçalho TCP e o cabeçalho IP, ou seja, ele conta apenas os dados não tendo o TCP SYN e o FIN. Lembrando-se que o TCP sobre Ethernet:

Adiciona 20 bytes para o cabeçalho IPV4 e 40 bytes para o cabeçalho IPV6
Adiciona 20 bytes para o cabeçalho TCP
Adiciona 12 bytes opcional para o TCP timestamps

Baseado nesses conceitos resolvi trazer uma situação real relacionando alguns pontos, para qual podemos enfrentar um problema devido ao pacote ser marcado com o df-bit ( não fragmentar ).

Segue a topologia abaixo como exemplo:

Nesse caso o cliente quer estabelecer uma conexão TCP com o servidor WEB, portanto eles anunciam o MSS deles para o outro para que eles aceitem o maior tamanho TCP nesse segmento. O valor negociado será de 1500 bytes, e o bit “ df-bit ” foi setado no servidor web, portanto esse pacote não poderá ser fragmentado. Quando o servidor devolver esse pacote para o roteador R2, ele irá tentar encapsular o pacote dentro de um túnel para entregar ao R1, porém o tunel GRE tem 24bytes a menos que o MTU configurado no servidor. Portanto o pacote irá ser fragmentado criando um pacote de 1476bytes ( dados e cabeçalho IP ) e um pacote de 44bytes ( 24bytes de dados e um novo cabeçalho IP de 20 bytes ). R2 irá encapsular ambos os pacotes de 1500bytes e 68bytes.

Mas você lembra-se que esse pacote não podia ser fragmentado devido ao df-bit, portanto R2 irá instruir o servidor WEB para enviar pacote menores. Isso significa que irá encaminhar um ICMP ( type 3 code 4 – Destination Unreachable; Fragmentation Needed and DF set ), para qual terá na mensagem o correto valor do MTU a ser usado pelo servidor WEB. Essa mensagem pode ser consultada através da RFC 1191 que trata do PMTUD, e também pode ser visualizada em um outro post através do wireshark mostrado para vocês.

Com isso podemos ter algumas soluções para resolver esse problema da fragmentação:

Modificando o bit ” df-bit “

!
interface FastEthernet0
…
ip policy route-map clear-df
!
route-map clear-df permit 10
match ip address 101
set ip df 0
!
access-list 101 permit tcp 10.1.3.0 0.0.0.255 any

Trocar o valor TCP MSS que comunica através do roteador. Isso será configurado através do comando disponível no IOS 12.2(4)T ou superior pelo ip tcp adjust-mss [ value ], colocando 1436 ( MTU menos o tamanho do IP, TCP, GRE ), ou seja, ( 1500 – 20 – 20 – 24 ).

interface tunnel0
…
ip tcp adjust-mss 1436

Alterar o valor do MTU configurado pela interface túnel

interface tunnel0
…
ip mtu 1500

Com isso podemos concluir que existem diversas formas de avaliar a sua rede em relação aos eventos que encontramos no dia a dia, portanto temos que analisar os pontos para encontrar o real problema de uma perca de pacote ou de uma lentidão reportada por algum usuário.

Espero que aproveitem e deixem seus comentários com experiências vividas em nosso dia a dia. 8)

Abs,
Rodrigo

Fonte:

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a0080093f1f.shtml
http://www.nil.si/ipcorner/IP_Fragmentation/
http://sd.wareonearth.com/~phil/net/overhead/