Alta disponibilidade em roteadores: Um ambiente de teste

Autor: Joao Eurıpedes Pereira Junior1,Orientador: PhD. Pedro Frosi Rosa1

1Programa de Pos-Graduacao em Ciencia da ComputacaoUniversidade Federal do Uberlandia (UFU)

Uberlandia – MG – Brasil

joao@dirpd.ufu.br, frosi@facom.ufu.br

Nıvel: MestradoAno de ingresso no programa: 2008

Epoca esperada de conclusao: Marco / 2010

Resumo. High available routers are crucial pieces of today’s internet. Virtual RouterRedundancy Protocol (VRRP) and Common Address Redundancy Protocol (CARP)are attempts to catch this need, but evolving customers and bussiness requirementsdrive the improvements of such solutions. This paper reflects a research (on progress)to understand this protocols and propose a test enviroment to observe their behaviorand collect information. This information will be compiled in a benchmark to supporta future architecture propose. The first test is defined and the experiment is described.Guidelines for other tests and related works are presented.

Palavras-Chave. Alta disponibilidade, VRRP, CARP

1. Introducao

O protocolo Virtual Router Redundancy Protocol (VRRP) foi projetado para elimi-nar o ponto unico de falha inerente aos ambientes de roteamento configurados estati-camente [Nadas 2008]. No entanto, existem alguns trabalhos, [G. Attebury 2006],[E. Lopes Filho ], [J. Kuo ], que citam o proprio VRRP como um ponto de falha. Comouma alternativa ao VRRP, que apresenta problemas tecnicos e teve a patente reclamadapela Cisco, a comunidade do OpenBSD desenvolveu o Common Address Redundancy Pro-tocol (CARP). O CARP permite que multiplos hosts compartilhem o mesmo endereco IP,dependendo da configuracao ele pode prover disponibilidade ou balanceamento de carga[car ].

Este documento registra uma pesquisa (em andamento), cujo objetivo e entender o fun-cionamento dos protocolos VRRP e CARP, e fazer um benchmark com esses protoco-los. Esse benchmark sera utilizado em uma fase posterior da pesquisa, que visa definiruma arquitetura de alta disponibilidade envolvendo o protocolo Stream Control Trans-mission Protocol (SCTP) [Steward 2007]. Com esse intuito, foi implementado um ambi-ente de teste com maquinas virtuais usando VRRP e CARP para simular roteadores dealta disponibilidade.

O ambiente de teste e apresentado na secao 2 e o primeiro experimento descrito na secao3. A secao 4 versa sobre os trabalhos relacionados e sobre como a pesquisa apresentadanesse trabalho pode ser extendida, restando as consideracoes finais para a secao 5.

2. O Ambiente de teste

Fısicamente o ambiente de teste se resume a um notebook com um processador Intel Core2 Duo T8300 e 2Gb de RAM, logicamente se resume a quatro roteadores, que serao usadosaos pares, dois para o protocolo VRRP e dois para o protocolo CARP, um cliente e umservidor.

O notebook roda o sistema operacional Linux, distribuicao Suse, versao 11.0, kernel2.6.25, onde foram criadas duas interfaces do tipo ponte (bridge), br0 e br1, e oito in-terfaces do tipo tap, numeradas de um a oito.

As pontes (bridges) sao equipamentos usados para unir varias LANs. No inicial todos osframes que entram por uma das portas da ponte sao repassados para as outras portas,mas apenas a interface cujo endereco Media Access Control (MAC) casa com o enderecode destino contido no frame o recebe. O frame e processado e devolvido para a ponte, quememoriza por qual porta a resposta retornou. O proximo frame enviado para o mesmodestino sera repassado apenas para a porta memorizada.

O Linux prove o recurso de ponte ethernet virtual, com a qual e possıvel criar instancias deponte e associar interfaces a mesma. Cada instancia de ponte funciona como foi descritono paragrafo anterior e todas as interfaces associadas a ponte sao equivalentes a portas.

As interfaces tap sao outro recurso oferecido pelo sistema operacional. Essas interfacessao tuneis ethernet entre o espaco do usuario e o espaco do kernel, o que permite que okernel e as aplicacoes troquem frames ethernet como se houvesse um enlace entre eles.Das oito interfaces tap criadas, as ımpares foram associadas a ponte br0 e as pares a pontebr1, formando assim duas redes locais de quatro interfaces cada uma.

Cada roteador e uma maquina virtual instalada usando o software VirtualBox e possuiduas interfaces de rede, associadas a uma das interfaces tap ımpar e a uma das interfacestap par. Uma das interfaces de rede de cada maquina virtual esta associada a uma das in-terfaces tap da maquina hospedeira que pertenca a ponte br0, enquanto a outra interfaceesta associada a uma das interfaces tap que pertenca a ponte br1.

A interface da ponte br0 foi configurada com o IP 192.168.0.254 e a interface da ponte br1foi configurada com IP 192.168.1.254. A interface do director1 associada a ponte br0 foiconfigurada com o IP 192.168.0.1 e a interface associada a ponte br1 foi configurada como IP 192.168.1.1. A interface do director2 associada a ponte br0 foi configurada com o IP192.168.0.2 e a interface associada a ponte br1 foi configurada com o IP 192.168.1.2. Ainterface do freebsd1 associada a ponte br0 foi configurada com o IP 192.168.0.3 e a inter-face associada a ponte br1 foi configurada com o IP 192.168.1.3. A interface do freebsd2associada a ponte br0 foi configurada com o IP 192.168.0.4 e a interface associada a pontebr1 foi configurada com o IP 192.168.1.4.

Linux Virtual Server (LVS) e um arranjo (cluster) de servidores Linux que prove servicosde alta disponibilidade e alto desempenho. Essas caracterısticas sao obtidas com o usodas tecnicas de failover, redundancia com substituicao automatica, e load balancing,distribuicao da demanda para varios servidores.

O LVS e composto por Directors e Real Servers. Os Directors fazem o balanceamentode carga e a redundancia entre os Real Servers, e funcionam como roteadores virtuais.Os Directors tambem suportam redundancia entre si para aumentar a disponibilidadedos servicos oferecidos pelo LVS. O papel dos Real Servers e prover servicos, exatamentecomo trabalham os servidores comuns da internet.

Figure 1. Gateway comum

O balanceamento de carga entre os servidores e feito por um modulo do kernel do Linux,chamado ipvs. O ipvs e um comutador (switcher) de pacotes baseado na pilha TCP/IP.Esse modulo mantem uma tabela, cujas informacoes sao usadas para decidir o destino dospacotes. A decisao tambem leva em conta o numero de conexoes que um Real Server estaatendendo, de maneira a deixar a carga nos Real Servers equilibrada. A caracterıstica debalanceamento de carga esta fora do escopo desse documento, para maiores informacoesvide [lvs ].

Figure 2. Gateway LVS

A redundancia entre os Directors fica a cargo do protocolo VRRP. O VRRP especificaum protocolo de eleicao que atribui dinamicamente a responsabilidade pelo roteador vir-tual a um dos roteadores VRRP na LAN. Inicialmente, um dos roteadores VRRP deveser configurado para assumir o controle (MASTER) do roteador virtual, todos os outrosroteadores VRRP da mesma instancia devem ser configurados para aguardar (BACKUP)ate que a instancia VRRP esteja sem um roteador VRRP MASTER. O roteador VRRPMASTER faz anuncios periodicos, mantendo todos os roteadores VRRP BACKUP a parda sua presenca. Quando o roteador MASTER deixa de enviar ou os roteadores BACKUPdeixam de receber os anuncios, e feita uma eleicao. O vencedor dessa eleicao se torna onovo roteador VRRP MASTER e assume o controle do roteador virtual.

Para que um servico oferecido por um LVS atinja a alta disponibilidade acoes precisamser constantemente tomadas em resposta a eventos, como falhas de software ou hard-ware. Essas acoes sao tomadas pelo Keepalived [kee ], um daemon controlador de LVS,em outras palavras, o keepalived monitora e manipula o servidor virtual, automatizandoas medidas e aumentando a disponibilidade.

A peca fundamental no ambiente de teste e o roteador virtual. No caso do protocolo VRRPo roteador virtual e um LVS, oferecendo o servico de roteamento (gateway) entre a LANe a internet, como mostrado na figura 2. O LVS e composto por duas maquinas virtuais,chamadas de director1 e director2. Cada maquina virtual possui duas interfaces de rede.Uma usada para conectar o host a LAN, e outra usada para conectar o host a WAN.

Nas maquinas virtuais que rodam o sistema operacional Linux, o softwarekeepalived-1.1.15 foi instalado e configurado para fornecer disponibilidade usando o pro-tocolo VRRP. A ferramenta net-snmp foi instalada e configurada de maneira a permitir acoleta de informacoes.

Duas maquinas virtuais rodam o sistema operacional FreeBSD 7.0. Elas tiveram o kernelrecompilado para habilitar o protocolo CARP, uma interface CARP foi criada e configu-rada em cada uma das maquinas. A ferramenta net-snmp foi instalada e configurada demaneira a permitir a coleta de informacoes.

3. Os TestesEm essencia os testes se constituem de um cliente fazendo requisicoes para e recebendorespostas de um servidor. Essas requisicoes e respostas tem que passar pelo roteador,

que embora seja unico do ponto de vista do cliente ou do servidor, e constituıdo semprede mais de um roteador (dois por questao de simplicidade). Esse arranjo (cluster) deroteadores tem a funcao de prover um servico de alta disponibilidade e/ou alto desem-penho. Os experimentos sempre tem o objetivo de demonstrar o funcionamento, preju-dica-lo ou interrompe-lo. Durante os mesmos, informacoes sao coletadas de maneira apermitir explicacoes mais precisas sobre o comportamento observado.

Figure 3. Trafego na pcn0 do freebsd2

Figure 4. Trafego na pcn0 do freebsd1

O primeiro experimento realizado com o ICMP, usando a ferramenta ping, cuja funcaoe verificar se o compartilhamento de IP entre os roteadores reais esta funcionando. O IPcompartilhado deve responder aos ICMP Requests com ICMP Replies, quando os doisroteadores estiverem funcionando, e quando apenas um deles estiver funcionando. O IPcompartilhado nao deve responder quando os dois roteadores estiverem desligados.

O endereco compartilhado pelo grupo de roteadores CARP e o 192.168.0.100, enquanto oendereco compartilhado pela instancia VRRP e o 192.168.0.200. Em duas sessoes de shelldistintas, a ferramenta ping foi chamada para enviar os requisicoes ICMP e receber as re-spostas, sendo uma chamada para cada endereco. Enquanto as respostas ICMP estiveremchegando e soubermos que pelo menos um dos roteadores esta ativo, o com partilhamentoestara funcionando.

No inıcio do experimento os dois roteadores Linux estavam funcionais, e verificou-se queos dois enderecos respondiam as requisicoes ICMP. Entao a interface eth1 do director1foi colocada no estado DOWN, verificou-se que o IP compartilhado deixou de responderpor um curto espaco de tempo, perdendo tres numeros da sequencia de identificacao dasrespostas ICMP, voltando a responder logo em seguida. O roteador VRRP director2, que

estava no estado BACKUP, passou para o estado MASTER, assumindo assim a respons-abilidade de responder aos ICMP Requests. Mais tarde a interface eth1 do director1 foicolocada no estado UP, verificando-se o mesmo comportamento da falha na sequencia derespostas ICMP, com o director1 voltando a responder as requisicoes ICMP e o director2voltando para o estado de BACKUP.

Os dois roteadores FreeBSD tambem iniciaram o experimento ambos funcionais e com ainterface 192.168.0.100 respondendo as requisicoes ICMP. A interface pcn0 do roteador dogrupo CARP,freesbd1, foi colocada no estado DOWN, verificou-se que o IP compartilhadodeixou de responder por um curto espaco de tempo, perdendo tres numeros da sequenciade identificacao das respostas ICMP, voltando a responder logo em seguida.

As figuras 3 e 4 mostram o trafego nas interfaces pcn0 dos roteadores freebsd2 e freebsd1,ambas participantes do grupo CARP. O roteador mestre do grupo CARP responde pelainterface 192.168.0.100. Foram enviadas cerca de 65 mil requisicoes ICMP durante osdias 12, 13, e 14. Cada requisicao possuıa o tamanho de 1000 bytes, gerando um trafegoaproximado de 8kbps. A area colorida representa o trafego de requisicoes e respostasICMP passando pela interface. Note que as reas coloridas estao alternadas, indicando queo CARP esta trabalhando no esquema de alta disponibilidade.

4. Trabalhos relacionados

Diferente do CARP, o protoloco VRRP contempla apenas a funcionalidade de disponibili-dade. Em [J. Kuo ] e proposta uma extensao do protocolo VRRP para prover a funcional-idade de balanceamento de carga. O trabalho [G. Attebury 2006] mostra um firewall dealta disponibilidade que utiliza CARP e pf, uma biblioteca para filtrar pacotes de rede.

Definido o ambiente de teste, resta definir novos parametros de interesse e consequente-mente novos experimentos. A princıpio existem tres grupos de experimentos, os de fun-cionalidade, os de desempenho, e os de seguranca. Os de funcionalidade tem a funcao dedeterminar se o arranjo esta ou nao funcionando, e em que situacoes e configuracoes elefunciona, ou deixa de funcionar. Os de desempenho servem mensurar em quais carac-terısticas, ou sob que situacoes um protocolo e mais eficiente que o outro. Os de segurancaidentificam como o servico pode ser alterado, forjado, ou interrrompido.

Nos experimentos de seguranca estao previstas aplicacoes capazes de gerar pacotes VRRPou CARP, que serao usadas para atacar os roteadores virtuais do ambiente de teste.

5. Consideracoes Finais

O ambiente de teste se mostrou uma ferramenta util, preenchendo as expectativas do au-tor em relacao a observacao do comportamento do funcionamento dos roteadores de altadisponibilidade. Os dados gerados durante o primeiro experimento, sobre o trafego dasinterfaces dos roteadores, ficaram armazenados em um banco de dados, permitindo ageracao de graficos. A recuperacao desses dados permitira no futuro uma analise es-tatıstica de caracterısticas dos protocolos VRRP e CARP, que sera resumida na forma deum benchmark.

References[carp] common address redundancy protocol http://www.freebsd.org/doc/en/books/handbook/carp.html acessado em 30/10/2008.

Keepalived http://www.keepalived.org/ acessado em 22/10/2008.

[lvs] the linux virtual server project http://www.linuxvirtualserver.org/ aces-sado em 22/10/2008.

E. Lopes Filho, G. Tadayoshi Hashimoto, P. F. R. A high availability firewall model based onsctp protocol.

G. Attebury, B. R. (2006). Router and firewall redundancy with openbsd and carp. IEEE ICC.

J. Kuo, S. Te, P. L. C. H. P. T. C. L. S. K. Y. H. Z. T. An evaluation of the virtual routerredundancy protocol extension with load balancing.

Nadas, S. (2008). [vrrp] virtual router redundancy protocol version 3 for ipv4 and ipv6.

Steward, R. (2007). [sctp] stream control transmission protocol.