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

[Igor Giangrossi]

Leandro,

O encaminhamento de pacotes via "flows" não depende do campo Flow Label do header IPv6. Como o valor do Flow Label é imposto pela aplicação (e não pela rede como por exemplo no MPLS), um router teria que olhar também o endereço de origem do pacote além do Flow Label para encaminhá-lo, pois existe a (remota) possibilidade de que hosts distintos usem o mesmo valor de Flow Label. Assim, não existiria ganho em olhar estes dois campos versus olhar apenas pro endereço de destino.

Já o conceito de Flow Based Routers utiliza um lookup inicial em vários campos do header de um pacote para gerar um hash interno que identifica cada fluxo. Após a geração deste hash, os pacotes subsequentes de um fluxo são encaminhados utilizando somente esta tabela de hash, sem lookups nas tabelas de rotas. Apesar de na teoria ser muito interessante, na prática pode ser difícil atingir um Flow Setup Rate suficientemente alto para não haver descartes, principalmente quando a rede está sob ataque. Além disso, mudanças na rede com muitos fluxos podem gerar instabilidades devido à necessidade de se modificar mutias entradas na tabela de hash ao mesmo tempo. Por isso os routers de alta performance hoje em dia fazem encaminhamento pacote a pacote com suas tabelas de rotas distribuídas nas linecards, e não baseando-se em fluxos.

Abs,
Igor

----- Original Message ----
From: Rubens Kuhl Jr. <rubensk at gmail.com>
To: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>
Sent: Saturday, October 27, 2007 9:28:57 PM
Subject: Re: [GTER] Continuido assuntos da GTER 24: IPv6, número de rotas

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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com