Existem diversas formas de planejar uma rede de telecomunica¸c˜oes para prevenir falhas, e cada vez mais surgem novos protocolos e configura¸c˜oes mais eficientes com o mesmo objetivo. O balanceamento de tr´afego ´e um exemplo de mecanismo que contribui para a preven¸c˜ao de falhas, pois reduz a forma¸c˜ao de gargalos na rede devido `a sobrecarga de roteadores. O ECMP (Equal Cost Multi-Path) ´e um protocolo usado para permitir o encaminhamento de pacotes utilizando m´ultiplos caminhos de custos iguais. O ECMP est´a definido na RFC 2992 [10]. Em um cen´ario onde existem duas ou mais rotas de custos iguais para determinadas redes de destino, o ECMP viabiliza uma distribui¸c˜ao mais uniforme do tr´afego sobre os caminhos dispon´ıveis, ajudando a prevenir congestionamento. Com um bom projeto t´ecnico em m˜aos e uma rede topologicamente bem montada, ´e poss´ıvel conceber boa simetria dos fluxos atrav´es das rotas de custos iguais. Durante eventos de falha, nos quais ocorre interrup¸c˜ao de uma ou mais rotas, o protocolo de roteamento utilizado na rede ser´a o respons´avel por encontrar as novas rotas. A Figura 7.2 exemplifica um caso em que existem dois caminhos diferentes para R1 se comunicar com R4, por´em esses dois caminhos possuem custos iguais. O custo dos dois caminhos entre R1 e R4 ´e 12, mas com o ECMP habilitado, R1 balanceia o tr´afego pelos dois caminhos poss´ıveis at´e R4, diminuindo a quantidade de tr´afego que passaria apenas por R2 ou apenas por R3.
Figura 7.2: Exemplo de uso do ECMP. O roteador R1 balanceia o encaminhamento dos pacotes utilizando as duas rotas de igual custo at´e R4.
O ECMP pode operar de duas formas. No balanceamento baseado em fluxo, o ECMP utiliza o resumo criptogr´afico originado a partir da 5-tupla que identifica o fluxo ao qual o pacote pertence e encaminha o pacote para a interface de sa´ıda adequada.
Todos os pacotes do mesmo fluxo TCP/IP ser˜ao encaminhados pela mesma interface. Esse ´e o m´etodo padr˜ao de funcionamento do ECMP [13]. No balanceamento baseado em pacote, o ECMP utiliza o modelo Round Robin, no qual fatias de tempo s˜ao atribu´ıdas a cada processo em partes iguais e em ordem circular, manipulando todos os processos sem prioridade, fazendo com que pacotes do mesmo fluxo possam seguir rotas diferentes [13]. Os dois modos de opera¸c˜ao do ECMP impactam diretamente protocolos como TCP ou Multipath-TCP1. Quando se utiliza o modo de balanceamento baseado em pacote, pacotes
que pertencem ao mesmo fluxo TCP/IP s˜ao encaminhados por rotas diferentes, o que pode causar reordena¸c˜ao nas esta¸c˜oes finais e, consequentemente, diminuir a taxa de transferˆencia. Quando o balanceamento baseado em fluxos ´e utilizado, o problema da entrega desordenada n˜ao ocorre pois todos os pacotes de um mesmo fluxo TCP/IP seguem a mesma rota.
1Conjunto de extens˜oes desenvolvidas para o protocolo TCP, que permite que os usu´arios dividam o tr´afego entre caminhos potencialmente disjuntos
Cap´ıtulo 8
Conclus˜oes e trabalhos futuros
Este trabalho realizou um estudo do funcionamento do protocolo de roteamento OSPF em uma rede backbone. Ademais, investigou-se o desempenho dessa rede quando m´ultiplas falhas ocorrem. Para tanto, utilizou-se o emulador de redes CORE, alimentado com a topologia da Rede Ipˆe da RNP. O fluxo de dados foi emulado com base em dados reais, obtidos a partir da ferramenta Panorama habilitada no site da RNP. O Panorama permite acompanhar o tr´afego da Rede Ipˆe em tempo real, sendo atualizado a cada 3 minutos.
Foram emulados quatro cen´arios distintos. No primeiro, a rede opera normalmente, sem falhas. Nos outros trˆes, provocam-se falhas em 1, 2 e 3 n´os simultaneamente. A sequˆencia de falhas segue um modelo baseado na centralidade de intermedia¸c˜ao dos n´os. Essa m´etrica ´e usada porque tem rela¸c˜ao com a capacidade dos n´os de intermediar fluxos que passam pelos caminhos de menor custo, calculados pelo OSPF. As falhas acontecem nos n´os mais centrais da Rede Ipˆe. No segundo cen´ario, falha-se o n´o mais central, CE. No terceiro, a falha ocorre nos n´os CE e DF. E no quarto, os trˆes n´os mais centrais, CE, DF e SP, s˜ao falhados simultaneamente. Nos trˆes cen´arios de falha, todos os n´os da rede continuam alcan¸cando uns aos outros. Uma falha adicional em n´o determinado pelo modelo de falhas utilizado provoca o particionamento da rede.
Estudou-se o funcionamento do OSPF com base no seu tempo de convergˆencia e na carga de controle gerada. J´a o desempenho da rede foi avaliado em termos de atraso e perda de pacotes de dados. O tempo de convergˆencia obtido para o OSPF foi de 1 minuto no cen´ario de opera¸c˜ao normal. Ap´os a convergˆencia, caso ocorra uma falha, o novo tempo de convergˆencia obtido foi de 40 segundos. O menor tempo se justifica por- que menos pacotes de controle precisam ser trocados para atualizar a topologia da rede
nos n´os. A carga de controle foi analisada com base no n´umero de pacotes OSPF tro- cados. Observou-se que durante o tempo de emula¸c˜ao pacotes Hello s˜ao constantemente trocados para manter ativos os enlaces entre vizinhos. J´a os pacotes de atualiza¸c˜ao de topologia (LSU), de base de dados (DBD), de solicita¸c˜ao de estado de enlace (LSR) e de reconhecimento de mensagens (LSAck), s˜ao trocados apenas durante o primeiro minuto de emula¸c˜ao, enquanto o protocolo ainda n˜ao convergiu. Quando uma falha ocorre, esses pacotes novamente s˜ao trocados para que a topologia possa ser atualizada e as novas rotas sejam calculadas. No entanto, menos pacotes s˜ao trocados comparado ao minuto inicial de emula¸c˜ao. Essa diferen¸ca se d´a pelo fato de que parte da topologia ainda ´e conhecida ap´os a falha, n˜ao havendo necessidade de redescobrir todos os estados de enlace novamente. Apenas os n´os impactados pela falha geram pacotes LSU.
Em rela¸c˜ao ao desempenho da rede, observou-se que o atraso aumentou com o crescimento no n´umero de falhas, conforme esperado. No entanto, o aumento ´e pequeno, mesmo para trˆes falhas simultˆaneas. A falha mais impactante no atraso ´e a primeira, do n´o mais central da rede. A medida que os outros n´os falham, o atraso aumenta cada vez menos. Isso demonstra que, com a altera¸c˜ao das rotas ap´os as falhas, as novas rotas encontradas aumentam pouco o custo m´edio dos caminhos, conseguindo manter o bom funcionamento da rede. A perda de pacotes apresenta um resultado diferente do esperado. Em geral, quando n´os falham, a tendˆencia ´e que alguns pacotes sejam perdidos enquanto a rota n˜ao ´e reestabelecida. Dessa forma, espera-se que a taxa de perda de pacotes cres¸ca com o aumento do n´umero de falhas. No entanto, com duas e trˆes falhas simultˆaneas, muitos fluxos pararam de funcionar, visto que a quantidade de fluxo passando somente por um n´o aumentou. Dessa forma, o resultado obtido para os cen´arios com duas e trˆes falhas em rela¸c˜ao `a taxa de perda de pacotes mascaram o desempenho da rede. Por mais que o emulador CORE n˜ao consiga retratar um cen´ario t˜ao fiel `a realidade, o estudo realizado ´e importante para o aprendizado de protocolos de roteamento e para identificar as poss´ıveis solu¸c˜oes para os problemas encontrados.
Como trabalhos futuros, pretende-se continuar a an´alise de desempenho da Rede Ipˆe quando o ECMP e o BFD est˜ao em opera¸c˜ao na rede. Para tanto, ´e necess´ario imple- mentar essas ferramentas no CORE, j´a que n˜ao s˜ao nativamente dispon´ıveis. Al´em disso, pretende-se utilizar outros simuladores que suportem roteadores de fabricantes emprega- dos na rede real para aumentar a confiabilidade dos resultados.
Referˆencias Bibliogr´aficas
[1] Marcio Roberto Seraggi Alex de Lima Cabral. Redes de computadores: Teoria e pr´atica. Senac, 2017.
[2] Douglas E. Comer. Redes de Computadores e Internet. Bookman, 2016.
[3] Rodrigo de Souza Couto. Estrat´egias e an´alise de resiliˆencia em redes de centro de dados. PhD thesis, UFRJ/COPPE, 2015.
[4] D. Ward D. Katz. RFC 5880 - Bidirectional Forwarding Detection (BFD), June 2010. [5] Marcelo Sampaio de Alencar. Engenharia de Redes de Computadores. ERICA, 2012. [6] Leonardo Barbosa e Oliveira. Avalia¸c˜ao de estrat´egias de roteamento ad hoc e t´ecni- cas peer-to-peer de localiza¸c˜ao de conte´udo em redes peer-to-peer sobre redes m´oveis ad hoc. Master’s thesis, UFMG, 2005.
[7] Jo˜ao Eriberto Mota Filho. An´alise de Tr´afego em Redes TCP/IP. Novatec, 2013. [8] Marco A FILIPPETTI. CCNA 4.1 – Guia Completo de Estudo. Visual Books, 2008. [9] C. Hedrick. RFC 1058 - Routing Information Protocol, June 1988.
[10] C. Hopps. RFC 2992 - Analysis of an Equal-Cost Multi-Path Algorithm, November 2000.
[11] Donato Antonio Marino Junior. Estrat´egias e m´etricas para resiliˆencia em redes de computadores. Master’s thesis, Instituto Militar de Engenharia, 2009.
[12] Ronaldo M. Salles Marcelo F. Vasconcelos. Emprego de resiliˆencia na gerˆencia de redes de comp radores. CE-RESD/SBC, page 12, November 2012.
[13] Fabio L. Verdi Marcus Sandri, Alan Silva. MultiFlow: Uma Solu¸c˜ao para Distribui¸c˜ao de Subfluxos MPTCP em Redes OpenFlow. UFSCAR, 2015.
[14] Marcelo Paiva da Motta. Topologia dos backbones de internet no Brasil. Sociedade & Natureza, pages 21 – 35 Vol. 24, April 2012.
[15] J. Moy. RFC 2328 - OSPF Version 2, April 1998.
[16] D. Oran. RFC 1142 - OSI IS-IS Intra-domain Routing Protocol, February, 1990. [17] C. Perkins. RFC 3561 - Ad hoc On-Demand Distance Vector (AODV) Routing, July
2003.
[18] Debora Santos, Luiz da Silva Mello, and Marco Antonio Grivet Mattoso Maia. En- genharia de tr´afego aplicada a redes verdes. SBrT2015, Setembro 2015.
[19] Muriel Medard Steven S. Lumetta. Reliability and fault tolerance. In Network Reli- ability and Fault Tolerance, Agosto 2012.
[20] P. Jacquet T. Clausen. RFC 3626 - Optimized Link State Routing Protocol (OLSR), Octuber 2003.
[21] David Tanenbaum, Andrew S.J. Wetherall. Redes de Computadores. Campus, 2011. [22] J. Tapolcai, P. Cholda, T. Cinkler, K. Wajda, A. Jajszczyk, A. Autenrieth, S. Boda- mer, D. Colle, G. Ferraris, H. Lonsethagen, I. . Svinnset, and D. Verchere. Quality of resilience (QoR): NOBEL approach to the multi-service resilience characterization. In 2nd International Conference on Broadband Networks, 2005., pages 1328–1337 Vol. 2, Oct 2005.