Quem já iniciou seus estudos para o CCNA já deve ter lido alguma coisa sobre os protocolos de roteamento proprietários Cisco: IGRP e EIGRP. Uma das características mais interessantes destes 2 protocolos é a capacidade que ambos possuem de balancear carga não apenas entre rotas com igual métrica para um dado destino, mas também com métricas desiguais. Para conseguir isso, é preciso configurar no (E)IGRP o parâmetro “variance”. Apesar de muito interessante, vou deixar este tema para um próximo post. Para quem se interessar e não quiser esperar , segue o link da Cisco:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009437d.shtml

Neste post, trataremos o balanceamento no EIGRP SEM a utilização do “variance”. Resolvi criar este post depois de uma “acalorada” e saudável discussão que surgiu estes dias, no fórum.

Balanceamento de carga entre caminhos de igual custo é realizado por quase todos os protocolos de roteamento (mesmo RIPv1). EIGRP não foge à regra. Se existerem até 6 caminhos para um dado destino com custos IDÊNTICOS, EIGRP fará o balanceamento entre estes 6 caminhos. Por exemplo, suponha o diagrama abaixo:

Nele, partindo do host VPC1, temos 2 caminhos distintos para a rede onde o host VPC2 se encontra. Um caminho passa pela rede 1.1.1.0 /30, enquanto outro, pela rede 2.2.2.0 /30. Vamos supor que ambos os links (s1/0 - s1/0 e s1/1 - s1/1) tenham custos idênticos. Como ficaria a tabela de roteamento, em R1, se tivéssemos EIGRP ativado em nossa rede?

Vamos observar:

R1>en

R1#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static routeGateway of last resort is not set

     1.0.0.0/30 is subnetted, 1 subnets

C       1.1.1.0 is directly connected, Serial1/0

     2.0.0.0/30 is subnetted, 1 subnets

C       2.2.2.0 is directly connected, Serial1/1

C    192.168.10.0/24 is directly connected, FastEthernet0/0

D    192.168.20.0/24 [90/2172416] via 1.1.1.2, 00:45:38, Serial1/0

                     [90/2172416] via 2.2.2.2, 00:45:38, Serial1/1

R1#

Podemos verificar que existem 2 rotas para a rede 192.168.20.0 na tabela de roteamento de R1. Uma pelo caminho 1.1.1.2 (s1/0-s1/0) e outra via 2.2.2.2 (s1/1-s1/1). Observamos também que as métricas são idênticas para ambas (2172416) - do contrário, o EIGRP não instalaria ambas na tabela de roteamento.

Bom, tudo muito bonito… mas… e o balanceamento??? Ocorre mesmo??? Como posso verifica-lo?

Em ambiente de laboratório, se possível, o melhor seria gerar um tráfego entre VPC1 e VPC2 e observar a carga diretamente nas interfaces. Como estou usando VPCS, isso não é possível. Um meio de verificar é via comando “sh ip route {rede}”, como no exemplo abaixo:

R1#sh ip route 192.168.20.0

Routing entry for 192.168.20.0/24

  Known via "eigrp 65000", distance 90, metric 2172416, type internal

  Redistributing via eigrp 65000

  Last update from 2.2.2.2 on Serial1/1, 00:52:37 ago

  Routing Descriptor Blocks:

  * 1.1.1.2, from 1.1.1.2, 00:52:37 ago, via Serial1/0

      Route metric is 2172416, traffic share count is 1

      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

    2.2.2.2, from 2.2.2.2, 00:52:37 ago, via Serial1/1

      Route metric is 2172416, traffic share count is 1

      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

R1#

Observem que, com este comando, conseguimos detalhes adicionais, que antes não foram apresentados utilizando-se apenas o “sh ip route”. O que quero mostrar aqui é o asterisco “*”. Notem que ele está ao lado da rota via 1.1.1.2. Isso siginifica que, o próximo pacote ou fluxo será enviado por esta interface. Bem, bem… isso deve significar então que, se estiver mesmo ocorrendo o balanceamento e eu der “ping” um número ímpar de vezes de VPC1 para VPC2 e der novamente o comando “sh ip route 192.168.20.0″ em R1, o asterisco deveria mudar para a rota via 2.2.2.2, certo?

Vamos ver se isso é mesmo verdade:

VPCS 1 >ping 192.168.20.2

192.168.20.2 icmp_seq=1 time=144.000 ms

192.168.20.2 icmp_seq=2 time=27.000 ms

192.168.20.2 icmp_seq=3 time=27.000 ms

192.168.20.2 icmp_seq=4 time=26.000 ms

192.168.20.2 icmp_seq=5 time=25.000 ms

VPCS 1 >

No VPCS, gerei 5 pings. Pela nossa lógica, o primeiro pacote deve ter saído via 1.1.1.2, o segundo via 2.2.2.2, o terceiro via 1.1.1.2, o quarto via 2.2.2.2 e o quinto, finalmente, via 1.1.1.2. Ou seja, o próximo pacote deveria sair via 2.2.2.2, que é onde nosso “*” deveria estar agora. Vamos checar:

R1#sh ip route 192.168.20.0

Routing entry for 192.168.20.0/24

  Known via "eigrp 65000", distance 90, metric 2172416, type internal

  Redistributing via eigrp 65000

  Last update from 2.2.2.2 on Serial1/1, 00:59:32 ago

  Routing Descriptor Blocks:

  * 1.1.1.2, from 1.1.1.2, 00:59:32 ago, via Serial1/0

      Route metric is 2172416, traffic share count is 1

      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

    2.2.2.2, from 2.2.2.2, 00:59:32 ago, via Serial1/1

      Route metric is 2172416, traffic share count is 1

      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

R1#

Hmmm, que interessante, não??? O “*” permanece na rota via 1.1.1.2! Isso significa que meu balanceamento não está funcionando???

Resposta: NÃO, não significa!

O que ocorre aqui é o seguinte: Roteadores Cisco possuem 2 modos para a realização de balanceamento de tráfego. Por destino e por pacote (Per-Destination and Per-Packet Load Balancing). Por destino significa que o router realiza o balanceamento do tráfego baseado no endereço IP de destino. Este é o modo default em roteadores Cisco que trabalham com o CEF (Cisco Express Forwarding) ativado. Como o CEF é praticamente obrigatório (por questões de performance e de alguns features dependerem dele para funcionar), especialmente em routers mais recentes, o balanceamento por destino é o modo padrão em um router Cisco.

Vejam exemplo:

R1#sh ip cef 192.168.20.0

192.168.20.0/24, version 17, epoch 0, per-destination sharing

0 packets, 0 bytes

  via 1.1.1.2, Serial1/0, 0 dependencies

    traffic share 1

    next hop 1.1.1.2, Serial1/0

    valid adjacency

  via 2.2.2.2, Serial1/1, 0 dependencies

    traffic share 1

    next hop 2.2.2.2, Serial1/1

    valid adjacency

  0 packets, 0 bytes switched through the prefix

  tmstats: external 0 packets, 0 bytes

           internal 0 packets, 0 bytes

R1#

Este tipo de balanceamento é mais eficaz quanto maior o número de destinos possível. Em nosso teste, temos apenas 1 destino e, portanto, o tráfego para este destino sempre irá sair por uma única rota, deixando o segundo link sem uso.

Para alterar o tipo de balanceamento para “por pacote”, basta utilizar o comando:

ip load-sharing per-packet

O problema é que, como este modo de balanceamento é extremamente custoso ao processamento do router, ele não é possível em todas as linhas. Em meu teste, por exemplo, utilizei 2 routers 3620. Estes não suportam balanceamento por pacote, apenas por destino:

R1#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

R1(config)#ip load-sharing per-packet
                  ^

% Invalid input detected at '^' marker.

R1(config)#ip cef ?

  accounting          Enable CEF accounting

  event-log           CEF event log commands

  load-sharing        Load sharing

  table               Set CEF forwarding table characteristics

  traffic-statistics  Enable collection of traffic statistics

  

R1(config)#ip cef load

R1(config)#ip cef load-sharing ?

  algorithm  Per-destination load sharing algorithm selection

R1(config)#ip cef load-sharing

Um modo simples e rápido de fazer o teste, então, é desabilitar o CEF (atenção, JAMAIS faça isso em um roteador em produção sem saber o que está fazendo!!!)

R1(config)#no ip cef

R1(config)#

E vamos testar nosso balanceamento novamente. Vou dar os 5 pings e checar a tabela de roteamento:

R1#sh ip route 192.168.20.0

Routing entry for 192.168.20.0/24

  Known via "eigrp 65000", distance 90, metric 2172416, type internal

  Redistributing via eigrp 65000

  Last update from 2.2.2.2 on Serial1/1, 01:20:25 ago

  Routing Descriptor Blocks:

    1.1.1.2, from 1.1.1.2, 01:20:25 ago, via Serial1/0

      Route metric is 2172416, traffic share count is 1

      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

  * 2.2.2.2, from 2.2.2.2, 01:20:25 ago, via Serial1/1

      Route metric is 2172416, traffic share count is 1

      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

E voilá!!! O asterisco mudou para o caminho via 2.2.2.2. Outra bateria de 5 pings e vamos verificar novamente:

R1#sh ip route 192.168.20.0

Routing entry for 192.168.20.0/24

  Known via "eigrp 65000", distance 90, metric 2172416, type internal

  Redistributing via eigrp 65000

  Last update from 2.2.2.2 on Serial1/1, 01:28:19 ago

  Routing Descriptor Blocks:

  * 1.1.1.2, from 1.1.1.2, 01:28:19 ago, via Serial1/0

      Route metric is 2172416, traffic share count is 1

      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

    2.2.2.2, from 2.2.2.2, 01:28:19 ago, via Serial1/1

      Route metric is 2172416, traffic share count is 1

      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

Ou seja, estamos balanceando por pacote! E como manter este balanceamento em links desiguais, utilizando EIGRP, sem o parâmetro “variance”?

Existem 2 maneiras. A primeira é alterar manualmente os valores que determinam a métrica do EIGRP nas interfaces. Basicamente o Bandwidth e o Delay. Ex:

r0(config)#int s0

r0(config-if)#bandwidth 10000

r0(config-if)#delay 100

Desta forma, você “engana” o protocolo, que vai calcular as métricas das rotas em cima destes valores e chegará a um mesmo resultado para ambos os caminhos. O outro método é utilizar uma lista “off-set”. Neste caso, nós manipulamos a métrica enxergada pelo EIGRP para que o resultado seja idêntico para 2 caminhos distintos. Este método é mais complexo e não vou comentá-lo neste post… para quem interessar, segue o link para referência:

http://ccnprecertification.com/2005/09/16/eigrp-load-balancing-without-using-variance/

Obviamente, “forçar” um protocolo a fazer um balanceamento por pacote nestes moldes não é aconselhável, já que caminhos para uma mesma rede possuem diferentes métricas reais (como velocidade do link, por exemplo). Mas não custa saber que é possível!

Ficamos por aqui! Espero que tenham gostado!

PS: Mais uma referência, para quem se interessar:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094820.shtml

Abs e boa semana,

Marco Filippetti

Popularity: 5% [?]

• Geradores de tráfego para labs
• [P&R] Redistribuição de Rotas - parte 3
• Implementando Pequenas Redes com Cisco
• [P&R] Redistribuição de Rotas - parte 2
• Questão CCNA - EIGRP
• Configuração de VLANs e VTP SEM usar o VLAN Database mode, no Dynamips
• Tutorial OSPF - Parte 6
• Roteamento por políticas - Policy-based Routing
• Redes Metro-Ethernet
• Tutorial OSPF - Parte 2
• [P&R] Redistribuição de Rotas - parte 1 (INTRO)
• [P&R] VRRP x HSRP x GLBP
• Tutorial IS-IS parte I
• Lab EIGRP para Troubleshooting
• [P&R] Tunelamento GRE (Generic Routing Encapsulation)

Este post foi postado Sunday, 20 de July de 2008 às 8:35 pm e está em Tecnologia, Exames CCNP, Artigos, Exame CCNA. Você pode verificar qualquer resposta a este post através do feed RSS 2.0. Você pode ir até o final e deixar uma resposta. Pings não são permitidos.