«

»

jul 20 2008

Balanceando tráfego com EIGRP (SEM o parâmetro Variance)

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:

labeigrp.gif

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



Comente usando o Facebook!
0
0

17 comentários

Pular para o formulário de comentário

  1. Minu

    Gostei do “JAMAIS” destacado hehe.

    Ótimo artigo!

    0

    0
  2. thais.gaspar

    Legal o artigo.

    Uma dúvida, como isso funcionaria para load-balance com dois links Internet. Pergunto, porque como o link é internet não dá para especificar uma rota, teria que ser uma rota default. Estou a duas semanas tentando implementar um load balance para dois links Internet usando PIX e Cisco 2611.

    ====Core6509==== PIX=====Router
    LAN

    Qualquer ajuda será muito bem vinda.

    Obrigada.

    0

    0
  3. Marco Filippetti

    Oi Thais,

    Para balanceamento de tráfego na internet, para balancear a saída, você teria que configurar 2 rotas default com mesmo custo em seu router. Estou supondo que BGP não está sendo utilizado. No lado da operadora, eles teriam que fazer o mesmo, apontando para o seu router, para balancear o tráfego tb na entrada.

    Se o balanceamento é entre 2 operadoras distintas, sem BGP, não é possível fazer o balanceamento na entrada. Porém, ainda é possível fazer na saída (via rotas default).

    Abs!

    Marco.

    0

    0
  4. thais.gaspar

    Obrigada pela resposta Marco.
    Mas infelizmente o PIX não suporta 2 rotas default. Como o NAT/PAT da minha rede é feito no PIX fico de mãos atadas.
    Já estou partindo para fazer o balanceamento usando um multilink ppp, como os dois links internet são da mesma operadora, acho que a melhor solução no meu caso é uma interface virtual.

    Obrigadaaaaaa.

    0

    0
  5. rodolphotdai

    marco esse ip load-sharing per-packet poderia também ser aplicado a interface para fazer o balanceamento por pacotes?
    Eu testei aqui da seguinte maneira e funcionou:

    router(config)#ip cef
    router(config)#int s0/1
    router(config-if)# ip load-sharing per-packet
    router(config)#int s0/2
    router(config-if)# ip load-sharing per-packet

    Me diz uma coisa esse ip load-sharing per packet aplicado a interface faria parte do ip cef?
    Porque quando eu emiti o sh ip cef ‘network’ aparecia per-packets sharing alterando o estado padrão. Como você havia comentado nem todas as linhas são capazes de suportar, dai eu tentei com uma imagem C7200-AD.BIN e não obtive exito. Outra coisa, trocando agora de situação, quando eu fiz esse post desabilitando o ip cef eu emiti um ping da minha máq. virtual para o router e só o primeiro ping alterou o asterisco do sh ip route “network”, o segundo, terceiro, quarto nada, dai eu gerei um ping do próprio router para a network e dei um sh ip route e deu sucessivamente todos os pings corretamente, para constar, eu verifiquei a conectivade da maquina virtual para o router, os ping eram contabilizados pelos pacotes de entrada da interface fast do router. Será que é assim mesmo?

    Brigado pela atenção e boa noite
    Abraços

    0

    0
  6. Marco Filippetti

    Oi Rodolpho, o método de load-sharing e o CEF não têm de estar obrigatoriamente relacionados, mas normalmente, estão.

    Não entendi seu teste… você pingou um roteador? Poderia explicar melhor o que você fez? Qual a topologia utilizada? A mesma que eu sugeri no post? Como ficou a tabela de roteamento? Pode passar mais detalhes…

    Abs!

    Marco.

    0

    0
  7. rodolphotdai

    Marco foi a mesma sugerida no post, quando eu gero um ping do VPC1 para o VPC2(com ip cef desabilitado) o interessante é que ñ troca de lugar o asterisco

    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

    Só altera quando eu gero um ping de R1 para VPC2. Detalhe é que eu pingo qualquer ponto apartir do VPC1.

    Abraços.
    Rodolpho

    0

    0
  8. rodolphotdai

    marco solucionado, desativei o ip route-cache nas duas interfaces e funcionou, reativei e nada, desativei e funcionou(constatado o erro), o router devia estar pegando o primeiro caminho em cache, assim desativado(no ip route-cache) ele optaria por pegar a informação na tab. de rotemento correto?

    Abraços
    Muito Obrigado.

    0

    0
  9. Marco Filippetti

    Ótimo Rodolpho! Apenas explicando, ao desativar o ip route-cache na interface você está desativando o fast switching nela. Mas faz sentido! Tem a ver com a plataforma utilizada por você (7200). Eu utilizei um 3600 nos meus testes.

    Legal você ter tentado! E mais legal ainda ter funcionado 😉

    Abs!

    Marco.

    0

    0
  10. veliah

    Só uma duvida sobre balaceamento só que utilizando o OSPF.
    POderia utilizar essa dica acima, para o OSPF j[a que o mesmo não tem o comando variance sendo assim não consigo realizar o balancemaento por caminhos com custos desiguais ?

    0

    0
  11. Marco Filippetti

    Oi Veliah! Sim, não vejo por que não…! Qualquer protocolo poderia ser usado.

    Abs!

    0

    0
  12. santospimentel

    Marco, nao entedi , me ajuda a esclarecer algumas duvidas .

    A técnica da comutação baseada em interrupção, pode ser feita através de três maneiras:
    I – Fast switching
    II – Optimum switching
    III – Cisco Express Forwarding (CEF)

    Eu posso ter os 3 modos na caixa ?
    – pra ativar o fast switch , uso o ip route cache ? e quando ativo , qual o modo de comutação , por destino ou pacote ??
    – o CEF é ativado por ip CEF ? e sei q por padrao é destino. Mas consigo coloca-lo por pacotes ??
    – e o Optimum switching , como funciona ??

    Obrigado

    0

    0
  13. santospimentel

    desculpa Marcos li novamente o post e vi q a pergunta ” o CEF é ativado por ip CEF ? e sei q por padrao é destino. Mas consigo coloca-lo por pacotes ?? ” esta respondida. No entanto me surgiu outra , rsrs, posso ter as 3 tecnicas de comutação na caixa?

    Grato.

    0

    0
  14. lfcunha

    Boa Tarde Marco, solicito ajuda, erro fiísco pode interferir no balanceamento

    router eigrp 109
    passive-interface FastEthernet0/0
    passive-interface Loopback0
    network 2.55.0.0 0.0.255.255
    network 3.55.0.0 0.0.255.255
    network 7.8.88.0 0.0.3.255
    network 7.8.92.244 0.0.0.3
    network 7.8.92.248 0.0.0.3
    network 7.8.0.0 0.0.255.255
    maximum-paths 2
    no auto-summary

    BRE#sh int summary

    *: interface is up
    IHQ: pkts in input hold queue IQD: pkts dropped from input queue
    OHQ: pkts in output hold queue OQD: pkts dropped from output queue
    RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)
    TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)
    TRTL: throttle count

    Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL
    ————————————————————————
    * FastEthernet0/0 0 0 0 0 919000 611 1829000 582 0
    * Serial0/0 0 0 0 12 1244000 355 427000 302 0
    * Serial0/0.1 – – – – – – – – –
    FastEthernet0/1 0 0 0 0 0 0 0 0 0
    * Serial0/1 0 0 0 10 535000 226 412000 304 0
    * Serial0/1.1 – – – – – – – – –
    * Loopback0 0 0 0 0 0 0 0 0 0
    NOTE:No separate counters are maintained for subinterfaces
    Hence Details of subinterface are not shown

    0

    0
  15. cleverson reneto

    gostei das perguntas e respostas . posso utilizar essas aplicações quando utilizo Qos de VOZ ? abs.

    0

    0
  16. samuelredel

    Marco,
    Se possível, gostaria da sua ajuda (ou a de alguém mais que esteja lendo esta):

    Tenho uma dúvida a respeito de qual rota um determinado roteador está enviando pacotes.

    Montei uma rede para efetuar testes de balanceamento de carga para meu TCC. Quando verifico a rota para a rede 192.168.1.0 de um determinado roteador tenho o seguinte resultado:

    Router0#show ip route 192.168.1.0

    Routing entry for 192.168.1.0/24

    Known via “rip”, distance 120, metric 1

    Redistributing via rip

    Last update from 192.168.4.2 on Serial2, 00:00:10 ago

    Routing Descriptor Blocks:

    * 192.168.4.2, from 192.168.4.2, 00:00:10 ago, via Serial2

    Route metric is 1, traffic share count is 1

    192.168.2.2, from 192.168.2.2, 00:00:10 ago, via Serial0

    Ou seja existem duas rotas de igual custo para o mesmo destino.

    Minha dúvida é: Qual rota o roteador irá escolher?

    Segundo a sua materia a rota a ser enviado o próximo pacote é a rota marcada com o *(asterisco).

    Porém quando rodo um #debug ip packet tenho o seguinte resultado (ao gerar um ping para um host da rede 192.168.1.0):

    Oct 30 17:22:16.339: IP: s=192.168.0.2 (FastEthernet0), d=192.168.1.133 (Serial0), g=192.168.2.2, len 60, forward

    Oct 30 17:22:16.359: IP: tableid=0, s=192.168.1.133 (Serial0), d=192.168.0.2 (FastEthernet0), routed via FIB

    Se o pacote está saindo pela Serial0…oque significa o asterisco?

    0

    0
  17. William

    Marco,

    Em meus estudos vi que, apesar de alguns roteadores não possuírem a opção de balanceamento per-packet no modo global, podemos aplicar esta configuração por interfaces:

    Router(config-if)# ip load-sharing per-packet

    Fonte: http://www.cisco.com/image/gif/paws/13677/19.pdf

    0

    0

Deixe uma resposta