[GTER] Continuido assuntos da GTER 24: IPv6, número de rotas

[Artur Renato Araujo da Silva]

Pessoal,

Alguém fez testes com Junipers? Eles dizem que a série M tem suporte em 
hardware:

"Hardware-based IPv6 and a number of IPv6 migration tools such as IPv6 
over MPLS, ease access to the
benefits of this next-generation IP protocol without performance 
compromise."

Fonte: http://www.juniper.net/products/mseries/100042.pdf

Artur





Rubens Kuhl Jr. wrote:
> On 10/27/07, Leandro M Bertholdo <berthold at penta.ufrgs.br> wrote:
>   
>> Ola Rubens,
>>
>> 1) O equipamento que testamos nao era cisco - era um switch router Extreme
>> (Extreme X450). Até onde eu sei esse é o primeiro que realmente implementa
>> v6 em hardware.
>>     
>
> Não confere. O primeiro equipamento com forward de v6 em hardware da
> Cisco foi a Sup720, inicialmente com o engine PFC3A. Depois ele vieram
> a PFC3B, a PFC3B-XL, e agora a PFC3C e a PFC3C-XL, usados na RSP 720.
> A Sup720 já tem uns bons anos, a primeira versão suportando-a é de
> Março de 2004.
>
> E eu nem ousaria dizer que a Cisco foi a primeira a lançar forwarding
> de IPv6 em hardware, acho mais provável que alguém tenha lançado
> antes... mas em Março de 2004 já havia.
>
>
>   
>> O nosso primeiro teste foi realizado com um cisco 2600 por software (o mesmo
>> teste) e tem resultados semelhantes ao que cistaste no modulo novo do 7200
>>     
>
> 7600. O 7200 é um roteador por software sempre.
>
>   
>> da cisco. O que me faz desconfiar "do quê" é implementado em hardware....
>>     
>
> O roteamento por software do 7600 tem o desempenho de um 7200, na casa
> de centenas de kpps (em dias ensolarados). O desempenho da ordem de
> Mpps do 7600 só acontece em hardware.
>
>   
>> Antes de realizarmos nossos testes ad-hoc, nós pesquisamos por testes
>> semelhantes em alguma fonte conceituada, e nao encontramos nenhum. Nao
>> realizamos teste com cisco por nao dispor de nenhum equipamento que
>> implementasse em hardware.
>>     
>
>
>
>   
>> Quanto ao modulo e o datasheet, acho dificil concluir que equipamento
>> realmente implementa roteamento ipv6 em hardware.
>>     
>
> Ele implementa sim, há mais detalhes de arquitetura disponível em
> apresentações da Networkers e em documentação fornecida a clientes com
> NDA. Os arquivos da lista cisco-nsp são uma boa referência onde essas
> informações estão disponíveis publicamente de forma esparsa.
>
>   
>> Alias, ele cita sutilmente:
>>
>> "The Cisco 7600 RSP 720 delivers a rich set of IP features in hardware for
>> applications such as subscriber aggregation, IP forwarding, Layer 2 and
>> Layer 3 MPLS VPNs, and Ethernet over MPLS (EoMPLS) with quality of service
>> (QoS) and security features."
>>
>> Ele nao fala em ipv6 forwarding em hardware....
>>
>>
>> 2) O router somente considera a rota para o setup do flow. Apos o
>> identificacao do flow montado o router nao se preocupa com os enderecos
>> origem e destino, ele usa a partir dai um identificador de flow.
>> [http://www.ietf.org/rfc/rfc1809.txt]
>>     
>
> Isso não acontece nem em roteadores Cisco com CEF nem em roteadores
> Juniper, que usam topology-based forwarding. Cada pacote é roteado
> independente dos anteriores; a acumulação de informações de fluxo, que
> antes era natural em função do switching do pacote, agora precisa de
> um mecanismo à parte. Nos Juniper sem J-Flow isso é feito com sampling
> para a Routing Engine, nos Cisco isso é feito nas PFCs mais recentes
> com uma flow memory à parte.
>
>   
>> ...
>> The notion is that by simply looking up the Flow Label in a table,
>>    the router can decide how to route and forward the datagram without
>>    examining the rest of the header.
>> ...
>> Sendo assim, o tamanho de bits da tabela de rotas so importa no primeiro
>> pacote.
>>     
>
> Isso pode acontecer no Extreme e na maioria dos modelos da Foundry, e
> é na minha visão a grande falha desses equipamentos. A resposta deles
> a DoS onde há um novo flow a cada pacote é muito ruim e causadora de
> instabilidades tremendas. Quer em IPv4 quanto em IPv6, esse tipo de
> teste dinâmico é algo em fazer para validar promessas de performance.
>
>
>   
>> Particulamente, eu gostaria de algum outro teste semelhante para nosso
>> comparativo, ja que algumas ferramentas usuais de testes nao tem suporte a
>> Ipv6 (ex: mgen, tangram...), se alguem quiser contrapor os testes,
>> particulmente tenho interesse em ver algum resultado ou repeticao destes
>> testes.
>>     
>
>
> Humm, vou ver se já tem suporte IPv6 nos Agilent que temos (não são de
> um modelo citado pela Agilent para IPv6, mas atualizamos recentemente
> a versão dele então talvez tenha algo novo) que temos para fazer uns
> testes com a PFC3C.
>
>
> Rubens
>
>
>   
>> []s
>> Leandro Bertholdo
>>
>>     
>>> -----Original Message-----
>>> From: gter-bounces at eng.registro.br [mailto:gter-
>>> bounces at eng.registro.br] On Behalf Of Rubens Kuhl Jr.
>>> Sent: sábado, 27 de outubro de 2007 15:21
>>> To: Grupo de Trabalho de Engenharia e Operacao de Redes
>>> Subject: [GTER] Continuido assuntos da GTER 24: IPv6, número de rotas
>>>
>>> Nas apresentações da GTER24 foram apresentados resultados que
>>> apontavam maior performance de roteamento IPv6 em equipamentos com
>>> IPv6 em hardware, lançados recentemente; eu gostaria de contrastá-los
>>> com o datasheet de um equipamento lançado este ano:
>>> http://www.cisco.com/en/US/products/hw/routers/ps368/products_data_shee
>>> t0900aecd8057f3b6.html
>>>
>>> Reproduzo alguns trechos:
>>>
>>> IPv4 routing
>>> In hardware
>>> Up to 400 Mpps*
>>>
>>> IPv6 routing
>>> In hardware
>>> Up to 200 Mpps*
>>>
>>> Routes
>>> 256,000 (IPv4); 128,000 (IPv6)
>>> 1,000,000 (IPv4); 500,000 (IPv6)
>>>
>>> Esse é um roteador distribuído com capacidade dependente do número de
>>> line-cards, em que a capacidade de roteamento IPv6 por cartão é a
>>> metade da capacidade IPv4. O mesmo acontece com o número de rotas;
>>> essa é uma conseqüência natural da limitação de banda de acesso a
>>> memória (um dos hard-limits tecnológicos que afetam tanto CPUs
>>> genéricas quanto dispositivos de propósito específico ), já que um
>>> prefixo IPv6 ocupa o dobro em bits de um prefixo IPv4 (o maior tamanho
>>> de prefixo em IPv6 é /64).
>>>
>>> Isso não significa que a velocidade diminuirá pela metade em uma rede
>>> constituída de equipamentos com essa característica; como boa parte
>>> das grandes redes IP do planeta operam em MPLS, o label size de 20
>>> bits faz que a velocidade de comutação seja igual ou
>>> muito próxima da de IPv4 em todos os rotedores P da rede; isso
>>> afetaria apenas a capacidade de roteadores PE de absorver pacotes IPv6
>>> para dentro do backbone MPLS.
>>>
>>> Vale reparar também que o número máximo de rotas cai pela metade
>>> considerando uma rede só-IPv6, e cai a 1/3 considerando o momento de
>>> pico da migração de IPv4 para IPv6 em que todas as redes estiverem
>>> operando em dual-stack. Comparando o número de rotas (256000) de um
>>> dos modelos desse equipamento, que é comum a vários equipamentos desse
>>> fornecedor comercializados na última década, com os números de rotas
>>> observados atualmente, vê-se também que as rotas IPv6 podem ser
>>> justamente as primeiras vítimas de otimização de um operador de rede
>>> que esteja em apuros por overflow de prefixos,
>>> diminuindo(infelizmente) o ritmo de adoção do protocolo.
>>>
>>>
>>>
>>> Rubens
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>       
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>>     
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>