Análise de desempenho de uma rede backbone na ocorrência de falhas múltiplas

(1)

Universidade Federal Fluminense

Escola de Engenharia

Curso de Gradua¸

c˜

ao em Engenharia de

Telecomunica¸

c˜

oes

Marcelo do Nascimento Venancio

Renan Martins Menezes

An´

alise de desempenho de uma rede backbone na

ocorrˆencia de falhas m´

ultiplas

Niter´

oi – RJ

2019

(2)

Marcelo do Nascimento Venancio Renan Martins Menezes

Análise de desempenho de uma rede backbone na ocorrência de falhas múltiplas

Trabalho de Conclusão de Curso apresentado ao Curso de Gradua¸cão em Engenharia de Teleco-munica¸cões da Universidade Federal Fluminense, como requisito parcial para obten¸cão do Grau de Engenheiro de Telecomunica¸cões.

Orientadora: Profa. Dra. Dianne Scherly Varela de Medeiros Co-orientador: Prof. Dr. Ricardo Campanha Carrano

Niter´oi – RJ 2019

(3)

(4)

Marcelo do Nascimento Venancio Renan Martins Menezes

Análise de desempenho de uma rede backbone na ocorrência de falhas múltiplas

Trabalho de Conclusão de Curso apresentado ao Curso de Gradua¸cão em Engenharia de Teleco-munica¸cões da Universidade Federal Fluminense, como requisito parcial para obten¸cão do Grau de Engenheiro de Telecomunica¸cões.

Aprovada em 11 de dezembro de 2019.

BANCA EXAMINADORA

Prof.a _Dr.a _{Dianne Scherly Varela de Medeiros - Orientadora}

Universidade Federal Fluminense - UFF

Prof. Dr. Ricardo Campanha Carrano - Co-Orientador Universidade Federal Fluminense - UFF

Prof. Dr. Luiz Claudio Schara Magalh˜aes Universidade Federal Fluminense - UFF

Prof. Dr. Diogo Menezes Ferrazani Mattos Universidade Federal Fluminense - UFF

Niter´oi – RJ 2019

(5)

Resumo

Os servi¸cos fornecidos pela Internet exigem cada vez mais uma alta disponibilidade da rede. O acesso a esses servi¸cos é feito através de redes de alta capacidade conhecidas como redes backbone. Considerando que os servi¸cos estão sempre ativos, para prover dis-ponibilidade é necessário que as redes backbone sejam tolerantes a falhas e apresentem desempenho aceitável mesmo quando múltiplas falhas ocorrem. Este trabalho tem como objetivo analisar o comportamento de uma rede backbone em opera¸cão normal e quando ocorrem múltiplas falhas em nós estratégicos para a comunica¸cão. Para isso, utiliza-se o Common Open Research Emulator (CORE) para emular a topologia de uma rede real, a Rede Ipê pertencente à Rede Nacional de Pesquisa (RNP) e que abrange todo o território nacional, com conexões internacionais. O protocolo de roteamento utilizado é o Open Shortest Path First (OSPF) e o fluxo de dados oferecido à rede tem como base dados reais obtidos a partir da ferramenta Panorama da RNP. O modelo de falhas empregado desativa os nós mais centrais da rede, sendo o número máximo de nós falhados igual a três. Investiga-se o tempo de convergência do protocolo OSPF, a carga de controle gerada por ele e o desempenho da rede em termos de atraso e perda de pacotes. Os resultados mostram que o atraso médio na rede apresenta pequeno aumento à medida que os nós mais centrais falham, sendo a falha do primeiro nó a mais impactante para essa métrica. Já a perda de pacotes aumenta para a primeira falha, mas diminui para as falha seguin-tes. Essa redu¸cão ocorre porque o número de fluxos comunicantes diminui e aqueles que permanecem ativos apresentam menor perda do que no cenário com uma falha. Esse re-sultado mascara o desempenho da rede, mas, de forma geral, a Rede Ipê apresenta bom desempenho mesmo quando os três nós mais centrais falham simultaneamente.

(6)

Abstract

Services provided over the Internet increasingly require high network availability. These services are accessed through high-capacity networks known as backbone networks. Since services are always active, to provide availability, backbone networks must be fault tole-rant and deliver acceptable performance when multiple failures occur. This project aims to analyze the behavior of a backbone network in normal operation and when multiple failures occur in strategic nodes for communication. Therefore, the Common Open Rese-arch Emulator (CORE) is used to emulate the topology of a real network, the Ipˆe Network belonging to the National Research Network (RNP) and covering the entire national ter-ritory, with international connections. The routing protocol used is Open Shortest Path First (OSPF) and the data flow offered to the network is based on actual data obtained from the RNP Panorama tool. The failure model used disables the most central nodes of the network, with the maximum number of failed nodes being equal to three. The emula-tion investigates the convergence time of the OSPF protocol, the control load generated by it and the network performance in terms of delay and packet loss. The results show that the average delay in the network increases slightly as the most central nodes fail, with the first node failure being the most impacting for this metric. Packet loss increases for the first failure, but decreases for the subsequent failures. This is due to a reduction in the number of flows and those that remain active have a smaller loss than a single failure. This result masks network performance, but overall, the Ipˆe Network delivers acceptable performance when the three most central nodes fail simultaneously.

(7)

Agradecimentos

Por tr´as de todas as conquistas em minha vida tive pessoas maravilhosas para me auxiliar nas decis˜oes.

Primeiramente, agrade¸co aos meus pais, Regina e Marcelo, por todo o esfor¸co, investimento e confian¸ca que tiveram em mim. Sem isso, nada seria poss´ıvel. Agrade¸co tamb´em a minha irm˜a Marina pela parceria durante todo o nosso crescimento juntos.

Agrade¸co também aos meus avós maternos, Manuel e Noélia, e avós paternos, Almir e Em´ılia, por toda ajuda e carinho na minha cria¸cão, além de toda a minha fam´ılia pelo apoio.

A todos os professores e amigos do Colégio Para´ıso, onde passei grande parte da minha infância e adolescência, em especial aos meus amigos Mateus, Juan, Ruan, Guilherme e Felippe que compartilharam momentos inesquec´ıveis ao meu lado.

Gostaria também de agradecer a todos os colegas que tornaram a minha trajetória na UFF mais fácil, em especial ao meu amigo e dupla de trabalho Renan e amigos Rodrigo, Gustavo, Charles e Maria Carolina por toda a ajuda. Quero agradecer ainda a todos os amigos da SmartTel Jr. pelos momentos juntos, além do crescimento profissional e pessoal. Por fim, não posso deixar de agradecer aos meus companheiros da Nokia, por toda a paciência e conhecimento compartilhado nesse meu in´ıcio de carreira, Alexandre, Fernando, Marcos e Leandro.

Todos os resultados da minha vida s˜ao parcelas de contribui¸c˜oes das pessoas que passaram por ela, obrigado.

(8)

Agradecimentos

Agrade¸co primeiramente aos meus pais João Luiz e Edna por investirem em meu futuro e sempre acreditarem em mim desde antes de entrar na universidade, me apoiando e incentivando nos momentos bons e ruins. Sou muito grato de tê-los como pais, eles são minha vida.

Ao meu irm˜ao Eric, que assim como meus pais, sempre me apoiou e esteve ao meu lado em todos os momentos. Agrade¸co pela for¸ca e compreens˜ao em todos esses anos.

`

A minha namorada Mariana, que esteve ao meu lado com palavras motivadoras e com pensamentos positivos durante a elabora¸cão deste projeto. À ela agrade¸co pela paciência, amor e carinho.

`

As minhas av´os Arlete, Maria L´ıdia e a toda a minha fam´ılia, por rezarem e torcerem por mim, ficando felizes a cada conquista.

Aos meus amigos Gustavo Nabuco, Rodrigo Ot´avio e Maria Carolina, por me acompanharem todos esses anos de faculdade, me ajudando e apoiando nos momentos de dificuldade.

Ao meu amigo e dupla de projeto Marcelo Venancio, pela parceria em todos os anos de faculdade, pelo esfor¸co e coopera¸c˜ao de sempre.

`

A minha professora orientadora Dianne, pela confian¸ca e coopera¸c˜ao durante o projeto.

`

A Universidade Federal Fluminense, por fazer parte de toda a minha trajetória até a forma¸cão.

(9)

Lista de Figuras

2.1 Rede Ipˆe simulada no EVE-NG. Cada estado possui um roteador, sendo a ´

unica exce¸c˜ao a Para´ıba, onde existem dois roteadores. . . 7 2.2 Topologia da Rede Ipˆe constru´ıda no CORE. . . 8 3.1 O roteamento entre diferentes ASes utiliza BGP, mas dentro de cada AS o

protocolo de roteamento utilizado pode ser diferente. . . 11 3.2 Custo no protocolo OSPF. O caminho de menor custo ser´a sempre

esco-lhido, sendo o custo total do caminho calculado como a soma dos custos dos enlaces que o compõe. No exemplo, o caminho de menor custo entre R1 e R4 é R1-R3-R4. . . 18 3.3 Cabe¸calho do Pacote OSPF. . . 19 3.4 Dom´ınio OSPF dividido em diferentes tipos de áreas OSPF. Todas as áreas

devem se conectar à área backbone. . . 23 4.1 Rela¸cão entre QoS, QoSR e disponibilidade de servi¸co. Um servi¸co

degra-dado pode estar dispon´ıvel desde que os parˆametros de QoSR n˜ao sejam

violados. (Adaptado pelos autores [22]) . . . 25 4.2 Parˆametros de QoS e QoR para defini¸c˜ao de classes de servi¸co. (Adaptado

pelos autores [22]) . . . 26 5.1 Infraestrutura da Rede Ipˆe em 2018. Os 27 PoPs servem mais de 1500

insti-tui¸c˜oes de ensino e pesquisa no Brasil. Existe ainda conex˜ao com backbones internacionais. . . 29 5.2 Qualidade do enlace entre o PoP-RJ e a UFF. No per´ıodo analisado, o

enlace apresentou uma média de perda de pacotes menor do que 1% e maior do que 0,01%, sendo sua qualidade classificada como boa. A latência média no per´ıodo foi de 1,95 ms. . . 30

(10)

5.3 Panorama de tráfego na Rede Ipê no dia 18/03/2019 às 13:45:12. Cada enlace mostra o tráfego em tempo real e as cores representam a carga sobre o enlace. Quando a carga está elevada, o enlace deixa de ser representado

na cor verde. . . 30

5.4 Emula¸cão de fluxo de dados na Rede Ipê utilizando o emulador CORE. Os fluxos são baseados no panorama da rede em 18/03/2019 às 13:45:12. . . . 34

5.5 Grafo da Rede Ipê. Cada PoP é representado por um nó e a liga¸cão entre PoPs adjacentes é uma aresta no grafo. . . 36

5.6 Grafo da Rede Ipê separada por regiões e gerado no software Gephi. Quanto maior o nó, mais central ele é. . . 37

5.7 Topologia após falha nos 5 nós mais centrais de cada região, PA, CE, SP, DF e PR. Ocorre particionamento da rede em 5 componentes. . . 38

5.8 Topologia após falha em nós mais centrais com recálculo da centralidade. Falha-se o nó mais central, CE, e, em seguida, falha-se o nó mais central da nova topologia, PE. Caso PE falhe, a rede é particionada. . . 39

5.9 Rede da RNP sem o n´o mais central . . . 40

5.10 Topologia ap´os falha nos dois n´os mais centrais, CE e DF. . . 40

5.11 Rede Ipê sem os três nós mais centrais, CE, DF e SP. . . 41

5.12 O fluxo TCP entre os n´os RN e AP segue o caminho marcado por enlaces representados por linhas mais largas. . . 42

5.13 Falha de um nó intermediário do fluxo entre RN e AP, execu¸cão do ping e do tracepath. No momento capturado na imagem, não existe chegada de mensagens de resposta do ping e do tracepath. . . 43

5.14 Após a convergência do protocolo de roteamento, o fluxo entre RN e AP ´ e reestabelecido e o terminal do nó RN mostra que as respostas do ping e do tracepath voltam a ser recebidas. . . 44

6.1 Histograma da quantidade de cada tipo de pacote OSPF no cen´ario sem falhas. . . 46

6.2 Histograma da quantidade de cada tipo de pacote OSPF no cen´ario com falha em CE. . . 47

6.3 Histograma da quantidade de cada tipo de pacote OSPF no cen´ario com falha em CE e DF. . . 48

(11)

6.4 Histograma da quantidade de cada tipo de pacote OSPF no cenário com falha em CE, DF e SP. . . 49 6.5 Atraso médio observado em cada cenário. À medida em que o número de

fa-lhas cresce, o atraso médio na rede também cresce, sendo mais significativo quando ocorre a primeira falha. . . 50 6.6 Taxa de perda de pacotes observada para cada cenário. O resultado obtido

para os cenários com duas e três falhas mascaram o desempenho da rede, uma vez que, apesar de a taxa de perda de pacotes ser menor, o número de fluxos comunicantes é reduzido em rela¸cão aos outros cenários. . . 51 7.1 Sessão BFD entre vizinhos OSPF. . . 53 7.2 Exemplo de uso do ECMP. O roteador R1 balanceia o encaminhamento

(12)

Lista de Tabelas

2.1 Critérios para a escolha do simulador . . . 9 3.1 Classifica¸cão e exemplos de protocolos de roteamento . . . 11 5.1 Valor da centralidade de cada nó . . . 37

(13)

Sum´

ario

Resumo iv Abstract v Agradecimentos vi Agradecimentos vii Lista de Figuras x Lista de Tabelas xi 1 Introdu¸c˜ao 1 1.1 Objetivos . . . 2 1.2 Estrutura do texto . . . 3

2 Simuladores e Emuladores de Redes de Comunica¸c˜ao 4 2.1 Escolha do simulador/emulador . . . 5

2.1.1 GNS3 . . . 5

2.1.2 EVE-NG . . . 6

2.2 CORE . . . 7

3 Protocolos de Roteamento 10 3.1 Classifica¸c˜ao dos Protocolos de Roteamento . . . 10

3.2 Protocolos de vetor de distˆancia . . . 12

3.2.1 RIP . . . 12

3.2.2 DSDV . . . 13

(14)

3.3 Protocolos de estado de enlace . . . 15

3.3.1 OLSR . . . 16

3.3.2 IS-IS . . . 16

3.3.3 OSPF . . . 17

4 Desempenho em Redes de Comunica¸c˜ao Resilientes 24 4.1 M´etricas de desempenho . . . 25

5 Emula¸c˜ao de uma rede de backbone 27 5.1 A Rede Ipˆe . . . 27

5.2 Metodologia . . . 31

5.2.1 Tempo de convergˆencia do OSPF . . . 31

5.2.2 Carga de controle do OSPF . . . 32

5.2.3 Atraso . . . 32

5.2.4 Perda de pacotes de dados . . . 33

5.2.5 Modelo de falhas . . . 34

5.2.6 Simula¸c˜ao de falha em n´os da rede . . . 41

6 Resultados e Análises 45 6.1 Estudo da opera¸cão do OSPF na Rede Ipê . . . 45

6.1.1 Tempo de convergˆencia . . . 45

6.1.2 Carga de controle . . . 46

6.2 Estudo do desempenho da Rede Ipˆe na presen¸ca de falhas . . . 49

6.2.1 Atraso . . . 50

6.2.2 Perda de pacotes de dados . . . 50

7 Estrat´egias para Melhoria de Desempenho 52 7.1 O protocolo Bidirectional Forwarding Detection . . . 52

7.2 O Equal Cost Multi-Path . . . 54 8 Conclus˜oes e trabalhos futuros 56

(15)

A C´odigos Desenvolvidos 60

A.1 C´alculo da centralidade de intermedia¸c˜ao . . . 60

A.2 Tratamento de arquivo de captura de pacotes . . . 62

A.2.1 Carga de controle OSPF e tempo de convergˆencia . . . 62

(16)

Cap´ıtulo 1

Introdu¸

c˜

ao

Os processos recentes de integra¸cão dos mercados por todo o mundo, de constru¸cão de fluxos financeiros globais e da integra¸cão das informa¸cões entre pa´ıses, regiões e cidades, ensejam a constru¸cão de infraestruturas f´ısicas robustas que permitam o transporte da informa¸cão [14]. A essa infraestrutura dá-se o nome de backbone, cujo papel é conectar as centrais das operadoras de Internet aos servidores externos nacionais e internacionais. Ele concentra o tráfego de várias redes locais e o transporta até o destino através de uma estrutura hierárquica, que garante o alto desempenho da rede e facilita tanto seu gerenciamento quanto o monitoramento do tráfego de dados. Os backbones nacionais conectam-se aos internacionais, que por sua vez conectam-se aos backbones de liga¸cão intercontinentais [5].

No Brasil, o primeiro backbone nacional nasceu em ambiente acadêmico, para aten-der a institutos de pesquisa e universidades [14]. O projeto deu origem à organiza¸cão social Rede Nacional de Ensino e Pesquisa (RNP), que opera a rede acadêmica denominada Rede Ipê. A Rede Ipê é um backbone nacional que atende a mais de 1.200 campi e unidades de ensino em todo o pa´ıs. Devido ao crescimento na demanda de transferências de dados, o backbone acadêmico da RNP tem elevado sua capacidade constantemente. Com uma ca-pacidade maior, facilita-se a troca de grandes volumes de dados, bem como a colabora¸cão entre brasileiros e pesquisadores no exterior.

A rápida prolifera¸cão de aplica¸cões baseadas nos protocolos da pilha TCP/IP e a expansão de aplica¸cões multim´ıdia, como jogos em rede, transmissão de v´ıdeos de alta resolu¸cão, videoconferências, telefonia IP e áudio digital, exigem cada vez mais largura de banda. Todo esse tráfego é transportado pelos backbones, isto é, os backbones podem

(17)

ser entendidos como uma rede principal por onde os dados da Internet trafegam. Assim, é notório que eles constituem infraestruturas cr´ıticas para a conectividade entre redes, uma vez que todas as redes locais dependem deles para alcan¸car servidores nacionais e internacionais. É essencial, portanto, que os backbones sejam projetados para suportar a demanda requisitada, provendo confiabilidade, alta disponibilidade e resiliência, mesmo em situa¸cões de múltiplas falhas de circuitos e roteadores [18]. Este trabalho foca no estudo da resiliência em redes backbone, que constitui um tema de grande importância no projeto de redes [11]. Para tanto, utiliza-se o emulador CORE para emular uma rede similar a topologia do backbone da RNP, a Rede Ipê. O objetivo é analisar o funcionamento de um protocolo de roteamento e verificar o desempenho da rede quando falhas ocorrem nos roteadores. Assim, é poss´ıvel investigar o quão tolerante a falhas é a topologia usada na Rede Ipê.

No estudo realizado neste trabalho, a rede é modelada como um grafo, em que os nós representam roteadores da Rede Ipê e as arestas são os enlaces entre esses roteadores. As falhas são representadas através da elimina¸cão do nó e das respectivas arestas que se conectam a ele. Em um primeiro momento, o objetivo é entender o protocolo de roteamento utilizado. Dessa forma, a rede é analisada com todos os nós em funcionamento e apenas os pacotes do protocolo de roteamento trafegam pela rede. Em seguida, investiga-se a troca desinvestiga-ses pacotes em caso de falha de nós espec´ıficos. Por fim, adiciona-se tráfego de dados à rede para analisar seu desempenho na ocorrência de falhas em nós estratégicos. Para tanto, algumas métricas de desempenho de redes são analisadas, como a taxa de perda de pacotes e o atraso. Os resultados mostram que para o atraso há um crescimento pequeno, a medida que mais nós são falhados. Em rela¸cão à taxa de perda de pacotes, ao crescer o número de nós falhados, percebe-se que alguns enlaces param de funcionar devido a baixa capacidade de um único nó processar diversos fluxos, ocasionando uma diminui¸cão da taxa de perda de pacotes, mesmo com mais nós falhados.

1.1 Objetivos

Este trabalho tem como objetivo investigar o desempenho de uma rede backbone na ocor-rência de múltiplas falhas em nós estratégicos para a conectividade da rede. Para alcan¸car esse objetivo, deve-se atingir os seguintes objetivos espec´ıficos: (i) estudar a teoria dos

(18)

protocolos de roteamento e de redes tolerantes a falhas, (ii) emular uma rede backbone, (iii) analisar a topologia da rede para identificar nós estratégicos e (iv) analisar o com-portamento da rede quando os nós estratégicos identificados falham.

1.2 Estrutura do texto

Este trabalho está organizado da seguinte forma. O Cap´ıtulo 2 apresenta um estudo sobre as caracter´ısticas de alguns simuladores, juntamente com a justificativa do simulador escolhido. O Cap´ıtulo 3 apresenta uma revisão teórica sobre o protocolo de roteamento utilizado nas emula¸cões. O Cap´ıtulo 4 apresenta o conceito relacionados à resiliência de uma rede de telecomunica¸cões e as métricas de desempenho utilizadas neste trabalho. O Cap´ıtulo 5 apresenta a base teórica sobre redes backbone, as caracter´ısticas da Rede Ipê e a metodologia utilizada nas medi¸cões feitas nas emula¸cões. O Cap´ıtulo 6 discute os resultados obtidos nas emula¸cões. O Cap´ıtulo 7 apresenta algumas solu¸cões propostas para os problemas encontrados. Por fim, o Cap´ıtulo 8 conclui este trabalho e apresenta dire¸cões futuras.

(19)

Cap´ıtulo 2

Simuladores e Emuladores de Redes

de Comunica¸

c˜

ao

A simula¸cão em computadores se iniciou na década de 60, junto com a introdu¸cão dos computadores no mercado [12]. Os simuladores de redes possibilitam a cria¸cão de uma topologia de rede para investigar seu comportamento sem que seja necessário implantar a rede fisicamente, utilizando cabos e equipamentos como comutadores, concentradores e roteadores. Assim, as dificuldades encontradas com instala¸cão de equipamentos, infraes-trutura, energia, espa¸co f´ısico e tantos outros, deixam de existir quando se usa simula¸cão em redes, possibilitando ao usuário focar na análise do que realmente importa. Exis-tem também os emuladores que, diferentemente dos simuladores, permitem emular em software o sistema operacional de dispositivos reais, como comutadores, concentradores, roteadores, dentre outros. A emula¸cão permite a intera¸cão com uma infraestrutura real de rede. Existem diversos programas diferentes para simula¸cão e emula¸cão de redes. Apesar de semelhantes e de servirem para um mesmo objetivo, cada programa possui desem-penho diferente, interfaces de usuário distintas e conjuntos variados de funcionalidades implementadas.

Neste cap´ıtulo, apresenta-se alguns dos simuladores/emuladores de rede existentes e justifica-se a escolha de um deles para o desenvolvimento deste trabalho. Todas as ferramentas apresentadas possuem as duas funcionalidades, emula¸c˜ao e simula¸c˜ao.

(20)

2.1 Escolha do simulador/emulador

Para a realiza¸cão dos estudos propostos neste trabalho, alguns critérios básicos devem ser atendidos pela ferramenta a ser escolhida, tais como: ser de fácil aprendizagem e permitir a simula¸cão da topologia da Rede Ipê, formada por 28 nós e 42 arestas, sem exaurir rapidamente os recursos de um computador pessoal de médio desempenho. O hardware utilizado conta com um processador Intel CORE i5 de 4a gera¸cão, 32 GB de memória RAM DDR4 e placa de v´ıdeo offboard. A seguir, apresentam-se caracter´ısticas dos simuladores de rede estudados, bem como a escolha do mais apropriado para este trabalho.

2.1.1 GNS3

O GNS3 (Graphical Network Simulator-3 )1 é um simulador de rede gratuito e de código aberto que provê interface gráfica para a cria¸cão de topologias nas quais cada nó é re-presentado por uma máquina virtual. Assim, todas as instâncias criadas competem com recursos de RAM e CPU do host. Além disso, são necessários alguns aplicativos terminais para acesso às instâncias criadas, dependendo do sistema operacional de cada uma delas, entre eles estão o PuTTY, VNC, Gnome Terminal, Windows Telnet Client, entre outros. O GNS3 é capaz de simular redes em tempo real, sem um Modo de Simula¸cão, ou seja, não é necessário iniciar uma simula¸cão, pois as instâncias criadas rodam independentemente do GNS3 estar aberto. Além disso, o GNS3 suporta mais de 20 fornecedores de rede diferentes em ambiente virtual e suporta ferramentas como o VPCS (Virtual PC Simu-lator ) e o Wireshark. O VPCS é uma instância que permite a simula¸cão de um simples computador com suporte a DHCP (Dynamic Host Configuration Protocol ) e ping. Já o Wireshark é um programa que permite capturar e analisar pacotes, contendo diversos filtros para agrupamento dos pacotes. Por também ser considerado um emulador, o GNS3 permite conexão com qualquer rede real, aproveitando o hardware e topologias existentes.

(21)

2.1.2 EVE-NG

EVE-NG (Emulated Virtual Environment )2_´_{e uma evolu¸c˜}_{ao da plataforma UnetLab.}

Pos-sui a maioria das caracter´ısticas do GNS3, como interface gráfica, necessidade de aplicati-vos terminais para acesso, realiza¸cão da simula¸cão em tempo real, suporte ao Wireshark e a possibilidade de conectar dispositivos reais. A lista de fabricantes que é poss´ıvel emular no EVE-NG é extensa, e inclui a Cisco IOS, IOS XE, IOS XR, ASAv, vWAAS, vIOS, vIOS L2, vNAM, vWLC, ESA, WSA, NX-OS, Cisco Firepower, CSR1000V, IOL), Juniper, Dell, F5, HP, Citrix, Mikrotik, Fortinet, PfSense, Palo Alto, Aruba, Alcatel, Check Point, entre outros. Possui um bom desempenho de CPU devido ao uso do KVM (Kernel-based Virtual Machine) e é de fácil instala¸cão.

Inicialmente, o EVE-NG foi utilizado para a simula¸cão proposta neste trabalho. A Figura 2.1 mostra a topologia da Rede Ipê como vista na interface gráfica do EVE-NG. Durante a simula¸cão, no entanto, a quantidade de nós da rede pretendida não foi suportada, fazendo com que esse simulador não fosse escolhido.

(22)

Figura 2.1: Rede Ipˆe simulada no EVE-NG. Cada estado possui um roteador, sendo a ´

unica exce¸c˜ao a Para´ıba, onde existem dois roteadores.

2.2 CORE

O emulador de rede CORE (Common Open Research Emulator )3 é uma ferramenta gra-tuita e de código aberto que permite simular e emular redes em uma ou várias máquinas. ´

E poss´ıvel criar os mais diversos cenários e configurar diferentes equipamentos de rede, que possuem um sistema operacional Linux genérico, sendo de fácil edi¸cão por meio de scripts. ´

E uma ferramenta recente e foi desenvolvida por um grupo de investigadores da divis˜ao

(23)

Boeing Research and Technology. Esse emulador utiliza o sistema operacional FreeBSD como sistema base. Segundo as especifica¸cões do CORE, versão 2015, suas principais caracter´ısticas são a usabilidade simplificada, a eficiência e a escalabilidade, a capacidade de execu¸cão de códigos instalados nos equipamentos, a possibilidade de interliga¸cão com redes reais, a disponibilidade do protocolo de seguran¸ca IPSec e a capacidade de simular redes sem fio.

Figura 2.2: Topologia da Rede Ipˆe constru´ıda no CORE.

Neste trabalho, o CORE é utilizado para o desenvolvimento das emula¸cões. A Figura 2.2 mostra a topologia da Rede Ipê emulada no CORE, conforme vista na interface gráfica do emulador. Ele atende aos critérios estabelecidos inicialmente para escolha do

(24)

simulador, é totalmente gratuito, e todos os nós possuem um sistema operacional de código aberto, tornando-os mais simples de serem editados individualmente. Essa última caracter´ıstica difere o CORE dos outros simuladores, já que eles utilizam imagens de sistemas operacionais para equipamentos existentes de diversos fabricantes distintos. O CORE, por não possuir essa funcionalidade, consegue emular um número maior de nós em compara¸cão com os outros simuladores, usando o mesmo hardware, sendo vantajoso para este trabalho devido ao tamanho da Rede Ipê. Além disso, a análise realizada não fica restrita ao software proprietário de equipamentos de fabricantes espec´ıficos. Para manter a generalidade da análise, dentre as ferramentas analisadas, o CORE é o mais indicado para o desenvolvimento deste trabalho. A tabela 2.1 ilustra as caracter´ısticas principais que orientaram a escolha desse emulador.

Tabela 2.1: Crit´erios para a escolha do simulador

GNS3 EVE-NG CORE

C´odigo Aberto X X X

Gratuito X4 X4 X

Capacidade de simular topologia da RNP no hardware utilizado X

F´acil Aprendizagem X

4_{O software em si ´}_{e gratuito, por´}_{em para utilizar determinado equipamento de um fabricante pode} ser necess´ario licen¸ca para tal.

(25)

Cap´ıtulo 3

Protocolos de Roteamento

As redes backbone que formam a Internet podem ser redes de empresas de telecomuni-ca¸cões (com fins comerciais), redes do governo e redes de pesquisa. Independentemente de sua origem, todas essas redes precisam seguir um padrão comum de funcionamento, para que exista interoperabilidade entre elas. Esse padrão de funcionamento é baseado no conceito de sistemas autônomos e algoritmos de roteamento padronizados. O processo de atualiza¸cão de rotas nos roteadores internos e de borda deve ser automatizado, isto é, a configura¸cão das tabelas de roteamento deve ser feita através de protocolos de ro-teamento padronizados, e não através de configura¸cão manual [2]. A finalidade de um algoritmo de roteamento é encontrar o caminho de menor custo entre todos os pares de nós origem-destino. É importante saber que o caminho de menor custo não é necessaria-mente o mais curto. Em uma rede espalhada geograficanecessaria-mente, o atraso total entre cada par origem-destino pode ser computado no custo, de modo que os caminhos por enlaces menos congestionados são as melhores escolhas [2]. Neste cap´ıtulo discute-se brevemente os principais protocolos de roteamento.

3.1 Classifica¸

c˜

ao dos Protocolos de Roteamento

Existem, basicamente, dois tipos de protocolos de roteamento: os protocolos de rotea-mento interno (Internal Gateway Protocol - IGP) e os protocolos de rotearotea-mento externo (External Gateway Protocol - EGP). Os IGPs atuam dentro de um mesmo Sistema Autˆ o-nomo (Autoo-nomous System - AS) e os EGPs atuam entre diferentes ASes. Um AS é uma rede ou conjunto de redes que está sob uma única administra¸cão ou pol´ıtica de

(26)

rotea-mento. Além dessa classifica¸cão, existe ainda a classifica¸cão quanto ao tipo de algoritmo utilizado. Os principais algoritmos são vetor de distância, estado de enlace, h´ıbrido e vetor de caminhos. Os protocolos baseados no algoritmo de vetor de distância utilizam apenas informa¸cões locais sobre a topologia da rede para calcular as melhores rotas. Já os protocolos de estado de enlace precisam de informa¸cão global sobre a topologia da rede. Em um protocolo de vetor de caminho, um roteador não recebe apenas o vetor de distância de um destino espec´ıfico de seu vizinho. Em vez disso, um nó recebe a distância e as informa¸cões do caminho que o nó pode usar para calcular como o tráfego é roteado para o AS de destino. Um exemplo de protocolo de vetor de caminho é o BGP (Border Gateway Protocol ). A Figura 3.1 ilustra a conexão entre dois ASes diferentes, que utilizam BGP para trocar entre eles informa¸cão sobre rotas. Dentro de cada AS, o protocolo de roteamento utilizado para obten¸cão das rotas pode ser diferente. A Tabela 3.1 mostra os diferentes tipos de protocolos de roteamento, com exemplos de padrão de cada classe.

Figura 3.1: O roteamento entre diferentes ASes utiliza BGP, mas dentro de cada AS o protocolo de roteamento utilizado pode ser diferente.

Tabela 3.1: Classifica¸c˜ao e exemplos de protocolos de roteamento

IGP EGP

Vetor de Distˆancia Estado de Enlace Vetor de Caminho Redes cabeadas Redes sem fio Redes cabeadas Redes sem fio Redes cabeadas

(27)

3.2 Protocolos de vetor de distˆ

ancia

O roteamento por vetor de distâncias compõe o grupo dos algoritmos de roteamento descentralizados, cujo cálculo do caminho de menor custo é realizado de modo iterativo e distribu´ıdo [1]. Por isso, nenhum nó tem informa¸cão completa sobre os custos de todos os enlaces da rede. Em vez disso, cada nó come¸ca sabendo apenas os custos dos enlaces diretamente conectados a ele. Então, por meio de um processo iterativo de cálculo e de troca de informa¸cões com seus nós vizinhos, um nó gradualmente calcula o caminho de menor custo até um destino ou um conjunto de destinos [1]. Basicamente, nos protocolos de vetor de distância cada nó mantém um vetor de estimativas de custos (distâncias) de um nó até todos os outros nós da rede. Alguns exemplos desses protocolos são apresentados nas subse¸cões seguintes.

3.2.1 RIP

O RIP (Routing Information Protocol ) é um protocolo de roteamento baseado no algo-ritmo de vetor de distância, projetado para ser usado como um IGP em redes de tamanho moderado com diâmetro máximo de 15 saltos. Esse número foi escolhido para equilibrar o tamanho da rede com a velocidade de convergência do algoritmo. A primeira versão do RIP foi descrita em 1988, na RFC (Request For Comments) 1058 [9].

Para indicar a distância até a rede de destino, o RIP utiliza como métrica a con-tagem de saltos da rota (hop count metric), na qual o número 1 (um) indica que os roteadores R1 e R2 são vizinhos, o número 2 (dois) indica que o roteador R1 é vizinho dos vizinhos de um roteador R2, e assim sucessivamente. Os roteadores do RIP mantêm, a cada momento, somente a melhor rota até o destino, isto é, a rota que possui o menor valor da métrica utilizada. Essa métrica não indica necessariamente o melhor caminho entre um par origem-destino. Fatores como largura de banda, estado de utiliza¸cão dos enlaces, entre outros, podem afetar a qualidade da rota, de forma que a rota mais curta em número de saltos não seja a rota mais eficiente. Sempre que o roteador atualiza sua tabela de roteamento, imediatamente ele transmite as atualiza¸cões sobre as informa¸cões de roteamento para informar aos roteadores vizinhos sobre as modifica¸cões ocorridas. Es-sas atualiza¸cões são emitidas independentemente das atualiza¸cões regulares programadas para serem enviadas periodicamente.

(28)

O RIP possui um limite para a contagem do número de saltos permitidos em um caminho de uma fonte até um destino. Esse limite é de 15 saltos, de forma que caminhos com 16 ou mais saltos são considerados inalcan¸cáveis. A defini¸cão desse limite é neces-sária para reduzir o tempo de convergência quando ocorre na rede o problema conhecido como contagem ao infinito. A contagem ao infinito acontece quando atualiza¸cões de rote-amento imprecisas fazem com que as tabelas de roterote-amento continuem sendo atualizadas, aumentando o custo para chegar a um destino que na realidade está inalcan¸cável.

3.2.2 DSDV

O protocolo DSDV (Destination Sequenced Distance Vector ) é um protocolo proativo, que atualiza as informa¸cões de roteamento regularmente [6], ou seja, periodicamente trocam-se informa¸cões sobre a rede com os nós, de modo a atualizar constantemente suas tabelas de roteamento. Ele é o resultado de uma das primeiras tentativas de adapta¸cão de um meca-nismo de roteamento para a aplica¸cão em redes móveis ad hoc. Originalmente o protocolo DSDV foi baseado no algoritmo de vetor de distância de Bellman-Ford. Posteriormente, o protocolo foi melhorado, sendo adicionada a capacidade de evitar la¸cos (loops) na rede que levam à contagem ao infinito.

No DSDV, cada nó na rede mantém uma tabela de roteamento com todos os destinos poss´ıveis, o número de saltos até o destino e um número sequencial atribu´ıdo pelo nó destino. O número sequencial é utilizado para distinguir novas rotas de rotas antigas, e, por isso, evitam la¸cos na rede. Em uma atualiza¸cão, a rota com o número sequencial mais recente será utilizada, enquanto a mais antiga é descartada. Quando uma rota com o mesmo número sequencial é recebida, a rota com o menor número de saltos será a rota preferencial, enquanto a outra rota é eliminada ou armazenada como não preferencial. Em resumo, as entradas da tabela de roteamento do protocolo DSDV possuem os campos: endere¸co IP do destino, endere¸co IP do próximo salto, número de saltos até o destino e número sequencial das informa¸cões recebidas sobre o destino.

A estratégia de manuten¸cão de rotas proativa faz a tabela de roteamento do proto-colo DSDV ser atualizada constantemente. Para evitar a gera¸cão de um grande tráfego de controle na rede provocado por essas atualiza¸cões, são aplicados dois tipos de atualiza¸cões: completa e incremental. Na atualiza¸cão completa, todas as informa¸cões de roteamento dispon´ıveis são transmitidas. Quando existem poucas mudan¸cas de topologia, as

(29)

atu-aliza¸cões completas são menos frequentes. As atualiza¸cões incrementais são utilizadas para trafegar as mudan¸cas ocorridas depois da última transmissão completa e ajudam a diminuir o tráfego gerado [5].

3.2.3 AODV

O protocolo AODV (Ad hoc On-demand Distance Vector ) é derivado do protocolo DSDV. Descrito na RFC 3561 [17], é um protocolo frequentemente discutido em pesquisas e muitas vezes comparado com outros protocolos. No AODV, quando um nó deseja se comunicar e uma rota não é conhecida, o nó de origem envia para toda a rede solicita¸cões de rota, iniciando o processo de descoberta. Para se evitar um grande impacto na ocupa¸cão da rede, essas solicita¸cões iniciais são enviadas com um valor de TTL (Time to Live) pequeno. Se nenhuma rota é encontrada, uma nova solicita¸cão é enviada com um TTL maior. Cada nó que retransmite o pedido acrescenta seu próprio endere¸co em uma lista presente no pacote.

Uma rota é encontrada quando uma solicita¸cão de rota atinge o nó de destino, ou quando atinge um nó intermediário que possui uma rota atualizada. Assim, utilizando a rota inversa, uma resposta é enviada para o nó de origem e cada nó intermediário pode armazenar a nova rota conhecida, armazenando apenas o próximo salto da rota e finalizando o processo de descoberta do protocolo. De acordo com a RFC 3561 [17], o protocolo AODV utiliza os seguintes campos para uma entrada na tabela de roteamento: endere¸co IP de destino, número de sequência de destino, estado de validade do número de sequência de destino, outros estados e controle de roteamento (válido, inválido, reparável), número de saltos para alcan¸car o destino, próximo salto, lista de precursores e tempo de vida.

No processo de manuten¸cão, a rota é atualizada quando o número de sequência da mensagem de atualiza¸cão é maior do que o do registro existente na tabela, assim atuali-za¸cões inconsistentes, com rotas mais antigas, não são permitidas. O nó também ignora múltiplas mensagens de solicita¸cão de rota com números de sequência iguais, impedindo la¸cos na rede. O estado dos enlaces das rotas ativas é monitorado através do envio pe-riódico de uma mensagem de verifica¸cão aos endere¸cos que constam no campo “próximo salto” da rota ativa. Quando uma falha no enlace é percebida, uma mensagem de erro de rota é usada para notificar outros nós sobre a falha. Essa mensagem é enviada

(30)

uti-lizando uma lista de precursores. A lista de precursores é composta dos endere¸cos IP dos nós vizinhos que o utilizam como próximo salto para atingir um destino, e é gerada a partir do processamento das mensagens de requisi¸cão de resposta. Cada entrada na tabela de roteamento recebe um tempo de vida, e este tempo é atualizado a cada vez que a rota é utilizada. O campo tempo de vida na tabela de roteamento tem dupla fun¸cão: para as rotas ativas significa o tempo de expira¸cão e, para as rotas inválidas, o tempo de elimina¸cão.

3.3 Protocolos de estado de enlace

O roteamento baseado em algoritmos de estado de enlace compõe o grupo dos algoritmos de roteamento global, pois calcula o caminho de menor custo entre uma fonte e um destino usando conhecimento completo e global sobre a rede. Em outras palavras, o algoritmo considera como dados de cálculo a conectividade entre todos os nós da rede e os custos de todos os enlaces. Logo, o algoritmo precisa obter essas informa¸cões antes de realizar o cálculo para encontrar as melhores rotas. O cálculo em si é executado em cada equipamento separadamente. Assim, a principal caracter´ıstica dos protocolos de estado de enlace é a necessidade de possuir informa¸cão completa sobre conectividade e custos para que, então, sejam computadas as melhores rotas.

O algoritmo de estado de enlace pode ser resumido de forma gen´erica da seguinte forma:

• Cada roteador obtém informa¸cões sobre suas próprias redes diretamente conectadas; • Cada roteador é responsável por anunciar para seus vizinhos em redes diretamente

conectadas;

• Cada roteador cria um pacote de estado de enlace que cont´em o estado de cada enlace diretamente conectado;

• Cada roteador encaminha o pacote de estado de enlace para todos os vizinhos atrav´es de um protocolo de inunda¸c˜ao e os vizinhos armazenam em um banco de dados todos os pacotes de estado de enlace recebidos;

• Cada roteador usa o banco de dados para criar um mapa completo da topologia e computa o melhor caminho para cada rede de destino.

(31)

Alguns protocolos de roteamento por estado de enlace são discutidos a seguir. Este trabalho foca no protocolo OSPF (Open Shortest Path First ), pois é o protocolo de roteamento interno mais utilizado nas redes atuais. Sendo assim, o OSPF é explicado mais detalhadamente.

3.3.1 OLSR

O protocolo OLSR (Optimized Link State Routing), descrito na RFC 3626 [20], consiste em um protocolo de roteamento proativo que foi desenvolvido para uso em WMN (Wi-reless Mesh Networks). A sua principal vantagem consiste no uso de nós especializados denominados MPRs (Multipoint Relay), limitando a quantidade de nós da rede que enca-minha pacotes de estado de enlace, a fim de que se possa eliminar mensagens redundantes e assim diminuir a quantidade de mensagens de controle duplicadas. Essa caracter´ıstica torna o OLSR adequado para ser usado em redes com alta densidade de nós. Além disso, o OLSR usa como critério de escolha de rotas o número de saltos.

Devido ao uso dos MPRs, o número de nós que retransmitem os pacotes é limitado. A escolha de cada MPR é feita por um consenso entre nós vizinhos, localizados a um salto de distância. Quando uma informa¸cão deve ser atualizada na rede, os pacotes enviados por um nó chegam a todos os seus vizinhos, mas somente aqueles denominados MPR podem retransmitir a informa¸cão adiante. Esse processo se repete com os próximos nós a receberem os pacotes. Dessa maneira, cada nó recebe apenas uma vez as informa¸cões. O protocolo OLSR constitui um modo mais organizado e eficiente de gerenciar o tráfego de pacotes de controle entre dois nós, sempre buscando o caminho mais curto.

O OLSR, por focar apenas no tráfego do melhor esfor¸co, pode acabar escolhendo caminhos com baixa qualidade (como por exemplo baixa vazão, atraso elevado, alta taxa de perda de pacotes, etc), e em fun¸cão disso diversas extensões têm sido propostas para resolver esta desvantagem.

3.3.2 IS-IS

O IS-IS (Intermediate System - Intermediate System) foi originalmente concebido como um protocolo de roteamento para redes ISO CLNP (Connectionless Network Layer Pro-tocol ), mas foi estendido para incluir o roteamento IP [8]. A vers˜ao estendida as vezes ´e chamada de IS-IS integrado.

(32)

Cada roteador IS-IS distribui informa¸cões sobre seu estado local, incluindo as in-terfaces utilizáveis e os vizinhos acess´ıveis, além do custo de uso de cada interface, para outros roteadores usando uma mensagem PDU (State PDU ) de enlace. Cada roteador usa as mensagens recebidas para criar um banco de dados idêntico que descreve a topologia do AS.

A partir do banco de dados, cada roteador calcula sua própria tabela de roteamento usando um algoritmo SPF (Shortest Path First ), também chamado de Dijkstra. Essa tabela de roteamento contém todos os destinos que o protocolo de roteamento conhece, associados a um endere¸co IP do próximo salto e à interface de sa´ıda. O protocolo recalcula as rotas quando a topologia da rede muda, usando o algoritmo de Dijkstra, e minimiza o tráfego de controle do protocolo de roteamento.

O IS-IS oferece suporte para utiliza¸cão de vários caminhos de igual custo e uma hierarquia de vários n´ıveis chamada de “roteamento de área” [16]. Essa hierarquia é importante para que as informa¸cões sobre a topologia dentro de uma área definida do AS sejam ocultas dos roteadores fora dessa área. Isso permite um n´ıvel adicional de prote¸cão e uma redu¸cão no tráfego do protocolo de roteamento. Ademais, todas as trocas de informa¸cões de roteamento do protocolo podem ser autenticadas para que somente roteadores confiáveis possam participar.

3.3.3 OSPF

O protocolo OSPF é um dos objetos de estudo deste trabalho. Ele foi desenvolvido para atender às necessidades colocadas pela Internet, que demandava um protocolo IGP eficiente, não proprietário e interoperável com outros protocolos de roteamento. Ele é enquadrado na categoria de protocolo de roteamento dinâmico, responsável por encami-nhar os pacotes de rede pelo caminho mais curto e baseando-se no algoritmo de estado de enlace.

Para computar o caminho mais curto, o OSPF se baseia nos custos dos enlaces. O custo de um enlace ´e calculado conforme Equa¸c˜ao 3.1.

Custo = Largura de Banda de Referˆencia

Largura de Banda , (3.1) onde a largura de banda de referência difere de equipamento para equipamento, sendo que a Equa¸cão 3.1 é apenas uma recomenda¸cão e não obrigatoriedade, pois é configurável.

(33)

Supondo uma largura de banda de referência de 100 Gb/s e um enlace de 10 Gb/s usado para chegar ao destino, o custo desse enlace seria 10. Já um enlace de 1 Gb/s teria custo 100. Portanto, o caminho escolhido usaria o enlace de 100 Gb/s. A Figura 3.2 mostra outro exemplo. O roteador R1 decide qual caminho escolher para se comunicar com R4 analisando as capacidades dos enlaces. O caminho superior, passando por R2, possui um custo total de 75, maior do que o custo do caminho inferior, passando por R3, que é igual a 30. Então, R1 escolhe o caminho inferior como melhor caminho, uma vez que ele possui o menor custo.

Figura 3.2: Custo no protocolo OSPF. O caminho de menor custo será sempre escolhido, sendo o custo total do caminho calculado como a soma dos custos dos enlaces que o compõe. No exemplo, o caminho de menor custo entre R1 e R4 é R1-R3-R4.

O pacote OSPF sempre possui um cabe¸calho padrão de 24 B. A Figura 3.3 mostra o conteúdo e o tamanho em bits de cada campo do cabe¸calho [15]. Os campos carregam as seguintes informa¸cões:

• Versão: indica o número da versão do protocolo OSPF; – 2: OSPFv2 opera com IPv4;

– 3: OSPFv3 opera com IPv6; • Tipo: indica o tipo do pacote OSPF;

• Tamanho do Pacote: indica o tamanho do pacote em bytes, incluindo o cabe¸calho; • ID do Roteador: indica o identificador do roteador que enviou o pacote;

(34)

• ID da ´Area: indica a ´area a qual o pacote pertence;

• Soma de Verifica¸cão: é um código usado para verificar a integridade de dados trans-mitidos. É aplicado ao pacote completo, incluindo o cabe¸calho, mas excluindo os 64 bits de autentica¸cão;

• Tipo de Autentica¸cão: indica o tipo de autentica¸cão a ser usado no pacote. Nor-malmente são três op¸cões;

– Sem Autentica¸c˜ao;

– Autentica¸c˜ao com senha simples;

– Autentica¸c˜ao MD5 (Message-Digest algorithm 5 );

• Autentica¸cão: informa o esquema de autentica¸cão a ser utilizado; – Sem Autentica¸cão nada é especificado (é usado por padrão);

– Autentica¸c˜ao com senha simples nada mais ´e do que um simples texto;

– Autentica¸cão MD5 permite usar uma chave de autentica¸cão a ser configurada por rede, roteadores no mesmo dom´ınio devem ser configurados com a mesma chave. É usado um resumo criptográfico para que a senha não seja divulgada abertamente por toda a rede.

(35)

O OSPF possui cinco tipos distintos de pacotes: 1. Pacote de aviso (Hello packet );

2. Pacote de informa¸cões do Banco de Dados (Database Description packet ); 3. Pacote de Requisi¸cão de estado de enlace (Link State Request packet ); 4. Pacote de Atualiza¸cão de estado de enlace (Link State Update packet );

5. Pacote de Reconhecimento de estado de enlace (Link State Acknowledgment packet ). O OSPF envia mensagens constantemente para manter a topologia da rede atua-lizada, essas são as mensagens Hello. Após a convergência das tabelas de roteamento, as mensagens com informa¸cões sobre a topologia são enviadas apenas quando ocorre alguma altera¸cão na topologia, isto é, quando um enlace é habilitado ou desabilitado, ou novos roteadores são inclu´ıdos na rede [8], essas são as mensagens Link State.

Quando um roteador é iniciado, o mesmo envia uma mensagem Hello por todas as suas linhas ponto-a-ponto, transmitindo-a por difusão nas LANs (Local Area Network ) até o grupo que consiste em todos os outros roteadores. Já para as WANs (Wide Área Network ), o roteador precisa de informa¸cões de configura¸cão para saber quem contatar. Com isso, os roteadores descobrem quem são seus vizinhos [21]. Na maioria dos equipa-mentos de diferentes fornecedores, o tempo padrão entre o envio de cada pacote Hello é de 10 segundos.

Cada roteador gera uma estrutura de dados conhecida como anúncio de estado de enlace (LSA - Link State Advertisement ) que descreve o estado local de uma rede ou do roteador. Para um roteador, o “estado” é composto pelo estado das interfaces do roteador e suas adjacências. Essa estrutura de dados deve ser inundada pela rede para que todos os roteadores passem a conhecer a topologia da rede. Existem diversos tipos de LSAs, dentre os quais os mais usados estão descritos a seguir. Cada tipo de LSA deve ser transportado em uma determinada área. A divisão da rede em áreas será discutida mais à frente, ainda neste cap´ıtulo.

• LSA tipo 1 (Router LSA): gerado por cada roteador para cada área à qual ele pertence e descreve o estado e os custos dos enlaces do roteador para a área;

(36)

• LSA tipo 2 (Network LSA): gerado por um DR (Designated Router ), que é res-ponsável pelo envio de LSAs em redes de acesso múltiplo, para descrever vizinhos conectados a um determinado segmento;

• LSA tipo 3 (Summary LSA 3 ): gerado pelo ABR (Area Border Router ) para des-crever a rota para vizinhos fora da ´area;

• LSA tipo 4 (Summary LSA 4 ): gerado pelo ABR para descrever a rota para um ASBR (Autonomous System Border Router ) para vizinhos fora da ´area;

• LSA tipo 5 (AS external LSA): gerado pelo ASBR para divulgar dentro da ´area as rotas externas para o AS;

• LSA tipo 7 (NSSA LSA): gerado pelo ASBR dentro de uma ´area NSSA (Not-So-Stubby Area) para divulgar dentro da NSSA as rotas externas para o AS.

Cada roteador emite por inunda¸cão mensagens Link State Update (LSU) para cada um de seus dispositivos adjacentes. Nessa mensagem estão contidas informa¸cões como estado e custo dos enlaces presentes no banco de dados da topologia. Em outras palavras, cada LSU carrega um conjunto de LSAs, podendo esse conjunto ser formado pelos LSAs de diversos roteadores. As mensagens LSU possuem um servi¸co confiável, ou seja, são confirmadas através de mensagens Link State Acknowledgement (LSAck). As mensagens também possuem número de sequência, onde o roteador pode ver se uma mensagem LSU recebida é antiga ou recente. Mensagens LSU também são enviadas quando um enlace é ativado ou desativado, ou quando os custos se alteram [21].

As mensagens Database Description (DBD) fornecem os números de sequências de todas as entradas de estado de enlace mantidas no momento pelo transmissor. Assim, o receptor pode comparar seus valores armazenados com os valores do transmissor, para verificar quem possui o registro mais recente. Em geral, essas mensagens são enviadas quando ocorre a interrup¸cão de um enlace.

Cada roteador pode solicitar informa¸cões de estado de enlace para os roteadores vizinhos usando mensagens Link State Request (LSR) quando detectam que seu banco de dados não está atualizado. Isso ocorre quando o roteador compara o DBD recebido com o seu próprio banco de dados. O roteador que recebe um LSR, responde com um LSU. Todas as mensagens OSPF são enviadas em pacotes IP [21].

(37)

Uma caracter´ıstica importante do protocolo OSPF é a possibilidade de dividir o dom´ınio OSPF em áreas menores, formando uma hierarquia entre as áreas. O dom´ınio OSPF é um conjunto de roteadores sob mesma administra¸cão. O roteamento entre as ´

areas é poss´ıvel através da utiliza¸cão dos roteadores de borda (ABRs). A forma¸cão de uma hierarquia entre as áreas permite que o OSPF seja usado em redes de grande escala. Isso é poss´ıvel porque o roteador de uma área só deve manter a base de dados da topologia da área a qual ele pertence. Assim, o roteador de uma área não tem conhecimento da topologia fora dessa área e compartilha seu banco de dados apenas com roteadores dentro da sua área e não com todo o dom´ınio OSPF. Com isso, reduz-se o número de LSAs e o tráfego de controle, além do tamanho da base de dados topológica que cada roteador deve manter [7]. Como consequência, os roteadores não precisam armazenar uma tabela de roteamento muito grande com rotas para todas as sub-redes. Isso tem impacto direto na utiliza¸cão da memória do roteador. Além disso, uma menor base de dados implica em menos LSAs para processar e, portanto, resulta em menor carga de processamento no roteador. Ademais, como a base de dados deve ser mantida apenas dentro da área, o algoritmo de inunda¸cão (flooding) é limitado a essa área, reduzindo a sobrecarga de controle na rede. Por tudo isso, percebe-se que há muitos benef´ıcios associados à utiliza¸cão da divisão por áreas do protocolo OSPF.

A divisão em áreas é poss´ıvel desde que sejam respeitadas as seguintes regras: • Deve existir uma rede backbone, que combina áreas independentes em um único

dom´ınio. A área backbone também é chamada de Área 0.

• Cada área que não seja a área backbone deve ser diretamente conectada na área backbone;

• A ´area backbone n˜ao pode ser particionada caso aconte¸ca alguma falha, como queda de um enlace ou de um roteador.

A Figura 3.4 ilustra um dom´ınio OSPF dividido em áreas. A área backbone é obrigatória e interconecta todas as outras áreas através de roteadores ABR. O roteador ABR é responsável por divulgar as rotas aprendidas para dentro de outra área e, portanto, deve sempre possuir pelo menos uma interface na área backbone e uma interface em outra ´

area. A área normal não possui nenhuma restri¸cão de distribui¸cão de LSAs. Os roteadores ASBR (Autonomous System Boundary Router ) presentes nas áreas normais realizam a

(38)

redistribui¸c˜ao de rotas de outros ASes para dentro do dom´ınio OSPF. No exemplo da Figura 3.4 o ASBR realiza a redistribui¸c˜ao de rotas do AS 65551 para o AS 65536, e vice versa.

Um ASBR na área NSSA propaga suas rotas para um ABR também na área NSSA, convertendo um LSA do tipo 5 para um LSA do tipo 7, propagando assim suas rotas para o restante do dom´ınio OSPF. A área stub não propaga rotas externas (LSAs do tipo 5). Para os roteadores da área stub alcan¸carem redes externas, o ABR precisa injetar uma rota padrão na área stub. Os ABRs também não propagam LSAs do tipo 4 neste tipo de ´

area, já que também são de rotas externas. Portanto, em uma área stub, as rotas externas são substitu´ıdas por uma única rota padrão. Por fim, a área totalmente stub também não recebe LSAs do tipo 4 ou 5 dos ABRs, por serem anúncios de rotas externas. Além disso, não recebem LSAs do tipo 3, que anunciam rotas para vizinhos fora da área. Todo o roteamento nessas áreas é feito com base em uma única rota padrão anunciada pelo ABR da área.

Figura 3.4: Dom´ınio OSPF dividido em diferentes tipos de áreas OSPF. Todas as áreas devem se conectar à área backbone.

(39)

Cap´ıtulo 4

Desempenho em Redes de

Comunica¸

c˜

ao Resilientes

A resiliência pode ser entendida como a capacidade da rede de manter n´ıveis aceitáveis de opera¸cão frente a anomalias, como sobrecarga operacional e falhas em equipamentos. A resiliência de uma rede depende de sua topologia f´ısica e da habilidade de seus pro-tocolos reagirem a falhas [3]. As redes backbone devem estar dispon´ıveis e operacionais o máximo de tempo poss´ıvel, proporcionando o melhor desempenho. Assim, é essen-cial que essas redes estejam preparadas para resistir aos problemas que levam à falta de conectividade, implementando medidas técnicas para mitigá-los, fortalecendo suas capa-cidades de defesa, deteçcão, remedia¸cão e recupera¸cão [11]. Sistemas preparados para prever antecipadamente os acontecimentos que levem à falta de conectividade podem rea-gir rapidamente, reduzindo o tempo de interrup¸cão dos servi¸cos prestados. Além disso, o crescimento exponencial de servi¸cos de missão cr´ıtica e outras necessidades de comunica-¸cão ininterrupta aumenta a necessidade de criar e manter redes cada vez mais robustas e tolerantes a falhas [19]. Por isso, estudos voltados para o aumento da resiliência em redes de comunica¸cão é um tema de suma importância.

Este cap´ıtulo apresenta um conjunto de métricas utilizadas para a análise de de-sempenho em redes de comunica¸cão resilientes e destaca aquelas usadas neste trabalho.

(40)

4.1 M´

etricas de desempenho

A qualidade de um servi¸co (QoS - Quality of Service) é medida através de métricas de desempenho, tais como atraso, jitter, taxa de erro de bits (BER - Bit Error Rate), taxa de perda de pacotes e largura de banda dispon´ıvel. De acordo com os valores encontrados para essas métricas, um servi¸co pode ser classificado em uma determinada classe. A Figura 4.1 mostra a rela¸cão entre QoS e a disponibilidade de um servi¸co. Se um servi¸co cumprir todos os parâmetros QoS definidos, ele é considerado com QoS compat´ıvel. Se algum parâmetro de QoS for violado, o servi¸co será considerado degradado. Um segundo conjunto de parâmetros de QoS pode ser definido para determinar a disponibilidade do servi¸co. Esses parâmetros são indicados como QoSR. A escolha do QoSR depende das

aplica¸cões [22]. O ajuste dos parâmetros de QoSR deve estar fortemente relacionado à

diferencia¸c˜ao das classes de servi¸co. Se os parˆametros QoSR forem violados, o servi¸co

será considerado indispon´ıvel. Caso contrário, o servi¸co está dispon´ıvel, podendo estar degradado, ou não.

Figura 4.1: Rela¸c˜ao entre QoS, QoSR e disponibilidade de servi¸co. Um servi¸co degradado

pode estar dispon´ıvel desde que os parˆametros de QoSR n˜ao sejam violados. (Adaptado

pelos autores [22])

A indisponibilidade de um servi¸co é geralmente causada por falhas inesperadas. A indisponibilidade de um servi¸co refere-se principalmente ao tráfego de pacotes. Isto é, um servi¸co é considerado indispon´ıvel não somente pela perda de sinal, mas também pelo desempenho da rede em rela¸cão à perda de pacotes e aos atrasos [22]. Para especificar a disponibilidade de um servi¸co podem ser mensurados alguns fatores de qualidade, cha-mados parâmetros de QoR (Quality of Resilience) [22]. O objetivo da QoR é caracterizar a probabilidade de um servi¸co estar dispon´ıvel. De acordo com a defini¸cão de QoR, um servi¸co deve atender aos requisitos de QoSR predefinidos. Os parâmetros de QoS, QoR e

(41)

QoSR est˜ao listados na Figura 4.2.

Figura 4.2: Parˆametros de QoS e QoR para defini¸c˜ao de classes de servi¸co. (Adaptado pelos autores [22])

O MTTR (Mean Time to Repair ) é o per´ıodo médio de tempo entre dois eventos. O primeiro é o in´ıcio da perda do servi¸co e o segundo é o in´ıcio do recebimento de um servi¸co adequado. O primeiro evento pode ocorrer devido a uma falha, enquanto o segundo pode ocorrer após um mecanismo de prote¸cão ou restaura¸cão ser bem sucedido. Neste trabalho, o MTTR pode ser definido como o tempo de convergência do protocolo de roteamento após uma falha. Isso é poss´ıvel porque após a convergência as rotas estão reestabelecidas e o servi¸co passa a ser oferecido novamente com perda de pacotes e atraso aceitáveis. O MTBF (Mean Time Between Failures) é o per´ıodo médio de tempo decorrido a partir de uma falha até que ocorra a próxima falha. Neste trabalho, o MTBF é considerado nulo, pois considera-se que as falhas ocorrem simultaneamente. O MTBF refere-se a toda interrup¸cão de servi¸co causada por falhas f´ısicas ou pela diminui¸cão da qualidade detectada. Como é notório, para conexões muito importantes, o servi¸co ininterrupto é necessário, independentemente de ocorrer mais de uma falha na rede. Por isso, cada vez mais métodos baseados em reconfigura¸cão cont´ınua são estudados e implantados nas redes [22].

A ideia apresentada neste trabalho está relacionada ao estudo da qualidade do tráfego de dados existentes nos enlaces de uma rede backbone. Mais especificamente, o foco é investigar o desempenho da rede em opera¸cão normal e após a ocorrência de múltiplas falhas em nós estratégicos. Para tanto, os parâmetros de QoS avaliados são a perda de pacotes e o atraso médio. A perda de pacotes também é parâmetro de QoSR.

(42)

Cap´ıtulo 5

Emula¸

c˜

ao de uma rede de backbone

As redes backbone são redes de alto desempenho e elevada capacidade que servem para transportar dados entre redes que se encontram em diferentes localidades, dentro ou fora de um pa´ıs. O primeiro backbone nacional nasceu no ambiente acadêmico. Esse projeto inicial deu origem à Rede Ipê, que pertence à Rede Nacional de Ensino e Pesquisa (RNP). Neste cap´ıtulo, apresenta-se a Rede Ipê e suas caracter´ısticas principais. A topologia dessa rede é utilizada em uma emula¸cão que tem como objetivo analisar o desempenho de uma rede backbone quando falhas ocorrem. A metodologia utilizada para análise do desempenho também é apresentada neste cap´ıtulo.

5.1 A Rede Ipˆ

e

A Rede Ipê é um backbone da Internet, operada pela RNP e dedicada à comunidade brasileira de ensino superior e pesquisa. Essa rede interconecta universidades e seus hospitais, institutos de pesquisa e institui¸cões culturais. A Rede Ipê foi inaugurada em 2005, como evolu¸cão de uma rede inicialmente implantada em 1992, e foi a primeira rede ´

optica nacional acadêmica a entrar em opera¸cão na América Latina. O projeto da Rede Ipê foi feito de forma a atender a demanda por capacidade de transmissão para trafegar dados de aplica¸cões básicas da Internet, como navega¸cão Web, correio eletrônico e transferência de arquivos, e para trafegar dados de servi¸cos avan¸cados, como aplica¸cões avan¸cadas e projetos cient´ıficos. Além disso, o projeto da Rede Ipê leva em considera¸cão a capacidade de fornecer suporte à experimenta¸cão de novas tecnologias, servi¸cos e aplica¸cões 1_.

(43)

A infraestrutura da Rede Ipê engloba 27 Pontos de Presen¸ca (PoPs), um em cada unidade da federa¸cão, totalizando 42 enlaces, além de ramifica¸cões para atender 1522 campi e unidades de institui¸cões de ensino, pesquisa e saúde em todo o pa´ıs, atendendo a mais de 3,5 milhões de usuários. A Figura 5.1, mostra a infraestrutura da Rede Ipê em 20182_{. A RNP disponibiliza diversas ferramentas online para obter informa¸c˜}_{oes sobre}

a Rede Ipê. Por exemplo, o Via Ipê3 permite acompanhar o tráfego e analisar diversas estat´ısticas dos enlaces entre os PoPs e as institui¸cões de ensino, como mostra a Figura 5.2. Já o Panorama4 permite acompanhar o tráfego da rede backbone em tempo real, sendo atualizado a cada 3 minutos. Um exemplo do Panorama está mostrado na Figura 5.3.

2_{Dispon´ıvel em https://www.rnp.br/sobre/nossa-historia/evolucao-da-rede-ipe} 3_{Dispon´ıvel em https://viaipe.rnp.br/#@-22.898513415051685,-43.11756134033203,14z} 4

(44)

Figura 5.1: Infraestrutura da Rede Ipê em 2018. Os 27 PoPs servem mais de 1500 institui-¸cões de ensino e pesquisa no Brasil. Existe ainda conexão com backbones internacionais.

(45)

Figura 5.2: Qualidade do enlace entre o PoP-RJ e a UFF. No per´ıodo analisado, o enlace apresentou uma média de perda de pacotes menor do que 1% e maior do que 0,01%, sendo sua qualidade classificada como boa. A latência média no per´ıodo foi de 1,95 ms.

Figura 5.3: Panorama de tráfego na Rede Ipê no dia 18/03/2019 às 13:45:12. Cada enlace mostra o tráfego em tempo real e as cores representam a carga sobre o enlace. Quando a carga está elevada, o enlace deixa de ser representado na cor verde.

(46)

Percebe-se, através da observa¸cão do tráfego capturado no dia 18/03/2019 mos-trado na Figura 5.3, que a rede backbone da RNP está funcionando sem falhas, com apenas alguns enlaces com carga de tráfego acima de 60%. Além disso, também é poss´ıvel verifi-car quais as redes interconectadas por esse backbone. Contudo, não é poss´ıvel afirmar que a todo momento a rede obedece esse padrão. Existem per´ıodos em que enlaces podem ficar inoperáveis ou atingir o limite de tráfego que o mesmo suporta. Neste trabalho, a topologia da Rede Ipê é emulada para entender como a rede reage à ocorrência de falhas e para analisar o seu desempenho nessas circunstâncias.

5.2 Metodologia

O desempenho da rede constru´ıda é analisado neste trabalho através de emula¸cões. Para tanto, utiliza-se o emulador CORE, alimentado com a topologia da Rede Ipê, incluindo a capacidade dos enlaces. Primeiramente investiga-se o comportamento do protocolo OSPF, utilizado para divulga¸cão de rotas na rede. Em seguida, métricas de desempenho de redes, como perda de pacotes e atraso, são mensuradas. As análises são feitas tanto para opera¸cão normal da rede, como para opera¸cão com falha. No CORE, cada nó da topologia é uma VM completamente funcional.

5.2.1 Tempo de convergˆ

encia do OSPF

Ao iniciar o estudo da Rede Ipê, primeiramente analisa-se o funcionamento do protocolo OSPF, sem a presen¸ca de fluxos de dados, para que seja poss´ıvel encontrar a distribui¸cão dos pacotes OSPF no tempo e, assim, calcular o tempo de convergência do protocolo na topologia da Rede Ipê. O tempo de convergência pode ser calculado como o tempo decor-rido até que os nós da rede escolham as melhores rotas de acesso entre eles, construindo uma tabela de roteamento. No OSPF, essa informa¸cão pode ser calculada através da medi¸cão do intervalo de tempo entre o envio do primeiro pacote Hello e o recebimento do ´

ultimo pacote LSU. Porém, além do tempo de convergência analisado quando a rede se inicia, ele também foi calculado a cada falha, sendo esse cálculo feito a partir do momento da falha até o último pacote LSU. Para esse fim, os pacotes gerados durante o tempo de emula¸cão são capturados para análise posterior. Essa análise pode ser feita através de programas como o Wireshark ou o Tcpdump. Para capturar pacotes durante a emula¸cão,

(47)

utiliza-se um script carregado em cada nó, que executa o comando Tcpdump em todas as interfaces do nó. Esse script é executado quando a emula¸cão inicia.

No emulador CORE, assim que uma emula¸cão termina, todos os nós são desligados. Consequentemente os terminais de cada nó são fechados e os arquivos de captura são automaticamente exclu´ıdos. Para contornar esse problema, cria-se um script que copia os arquivos de captura para um diretório no host no momento que a emula¸cão é finalizada. Os arquivos de captura armazenados no host são processados utilizando códigos Python desenvolvidos para cada análise realizada.

5.2.2 Carga de controle do OSPF

Na análise seguinte, investiga-se a sobrecarga de controle provocada pelo OSPF na rede. Essa sobrecarga é medida como o número de pacotes OSPF que trafegam na rede durante o tempo de emula¸cão. Com base nos arquivos de captura armazenados no host, um código Python é utilizado para contar a quantidade de cada tipo de pacote OSPF em todas as interfaces. Calcula-se então a soma de todos esses pacotes trafegados na rede, que finalmente é plotada em um gráfico. Esse processo é repetido 4 vezes, uma vez para cada cenário. No primeiro cenário, considera-se opera¸cão normal da rede. Do segundo ao quarto cenário, ocorrem falhas em nós estratégicos da rede.

5.2.3 Atraso

O atraso é um parâmetro utilizado para determinar a QoS de um servi¸co. Esse parâmetro pode ser entendido como o tempo de ida e volta em uma comunica¸cão (RTT - Round-Trip Time). No comando ping, o RTT é carregado no campo de tempo de resposta. Para avaliar o atraso na emula¸cão, utiliza-se um script em cada nó para executar e armazenar a sa´ıda do comando ping em um arquivo de texto na máquina host. Dessa forma, cada nó executa um ping para cada um dos nós da rede. Em seguida, utilizando um código desenvolvido em Python, lê-se todos os arquivos de sa´ıda gerado para se obter uma média de todos os atrasos.

(48)

5.2.4 Perda de pacotes de dados

Para medir a perda de pacotes, são criados fluxos com tráfego de dados TCP de acordo com o observado na Figura 5.3, porém com uma escala de unidade de bits reduzida por um fator de 100, pois o emulador CORE possui um limite de banda de 1 Gb/s.

A Figura 5.4 mostra o ambiente de emula¸cão com exemplos de fluxos de dados criados. A perda de pacotes é calculada para os 4 cenários já citados, considerando ope-ra¸cão normal e com falha. Já os fluxos criados para esses cenários variam periodicamente em valores próximos a 85% da capacidade de cada enlace criado no emulador, passando inclusive pelos nós escolhidos para falhar, para que quando ocorressem as falhas novas rotas fossem recalculadas.

(49)

Figura 5.4: Emula¸cão de fluxo de dados na Rede Ipê utilizando o emulador CORE. Os fluxos são baseados no panorama da rede em 18/03/2019 às 13:45:12.

5.2.5 Modelo de falhas

Uma das caracter´ısticas que podem ser observadas na Rede Ipê é a sua complexidade e capacidade de interliga¸cão e conexão entre os diferentes nós. Essa é uma caracter´ıstica chave de uma rede em malha, que é muito bem aproveitada em situa¸cões de quedas de enlaces e falhas de nós. Isso ocorre porque topologias em malha possuem um grande n´ u-mero de rotas entre os nós, de forma que a probabilidade de a rede perder a conectividade é reduzida. A Rede Ipê, no entanto, não é uma malha completa e, portanto, os nós não estão ligados diretamente uns aos outros e uma falha pode ser catastrófica, particionando