Roteiro de Práticas de Roteamento EGP usando Quagga

Transcrição

1 Roteiro de Práticas de Roteamento EGP usando Quagga BGP O objetivo desse roteiro é mostrar como o pacote Quagga pode ser utilizado para construir roteadores com suporte a protocolos de roteamento utilizando Linux. No Linux, as principais funções de roteamento estão implementadas ao nível do Kernel. Contudo, os protocolos de roteamento são considerados aplicações de mais alto nível, e não estão no Kernel. O Quagga não altera as funções de roteamento do Kernel do Linux. Ele é um pacote de alto nível que introduz os protocolos de roteamento e uma interface de gerenciamento de alto nível. A função do Quagga é preencher de forma automática as tabelas de roteamento. É possível fazer um roteador com Linux sem utilizar o Quagga. Nesse caso, as tabelas de roteamento deverão ser configuradas de forma manual. A apresentação do Quagga feita nesta apostila é similar a feita anteriormente para as práticas de RIP e OSPF. Dessa forma, o aluno que já tenha feito as práticas anteriores pode referir-se diretamente a página 3 da apostila.

2 Pacote Quagga telnet 2605 bgpd administrador telnet 2601 Zebra bgpd.conf rotas Kernel do Linux (Roteamento) zebra.conf roteador O "Quagga Routing Suite" utiliza dois programa para implementar roteadores com suporte ao protocolo de roteamento BGP: zebra e bgpd. O zebra é um programa que faz a "cola" entre o sistemas operacional e o "bgpd". Para que um computador com Linux consiga operar como um roteador com suporte a BGP ambos os programas, zebra e bgpd, precisam estar sendo executados simultaneamente. Os programas em quagga podem ser executados em primeiro plano (as mensagens de erro são enviadas diretamente na tela) ou como deamons (os programas são executados sem usar recursos de janela, e depositam suas mensagens de erro no arquivo de log - /var/log/messages). A configuração dos programas pode ser feita de duas formas. Alterando os arquivos de configuração (que geralmente são localizados na pasta /etc/quagga) ou dando-se um telnet na porta de controle dos programas. Geralmente, editar os arquivos de configuração é bem mais simples. A opção de telnet existe para permitir o gerenciamento remoto dos roteadores Quagga. A sintaxe dos comandos do Quagga é muito similar aos equipamento que seguem o IOS da cisco. Após dar telnet em um programa, tem-se acesso a um conjunto de comandos que podem ser listados com "?". Sempre que se tiver dúvidas sobre um comando, basta digitar "?" que será fornecido a lista de parâmetros disponíveis para o comando. Por exemplo, se você digitar no zebra: >> show? Serão fornecidas duas opções para completar o comando: route ou ip_forward. A primeira opção mostra as tabelas de roteamento e a segundo mostra se o roteamento está habilitado ou não. Os comandos disponíveis inicialmente via telnet não suportam alterações no roteador, apenas visualização da configuração corrente. Para poder alterar a configuração do roteador (por exemplo, habilitar remotamente o roteamento) é necessário digitar o comando "enable". Após o comando "enable" uma lista mais ampla de opções estará disponível quando se digitar "?".

3 BGP: Descrição do Cenário / /24 AS2 VM /8 AS1 VM /24 AS3 VM3 Ponto de Troca (IXP/ PTT) /8 Código estudante: (101) X /8 A figura ilustra como será o cenário completo de BGP. Nessa prática, serão utilizadas três máquinas virtuais: VM1, VM2 e VM3. Cada uma das máquinas virtuais irá fazer o papel de um roteador de borda de um AS. Os endereços IP listados no cenário deverão ser modificados de acordo com o código de estudante de cada aluno. O exemplo foi elaborado considerando-se o seguinte código: (101) x. Observe que apenas os 4 números menos significativos antes do '-' são utilizados na montagem dos endereços IP. Cada um dos AS tem um prefixo correspondente, definidos da seguinte forma: AS1 : prefixo /24 AS2 : prefixo /24 AS3 : prefixo /24 Num AS completo, deveriam também existir roteadores IGP, executando, por exemplo, OSPF. Contudo, é possível ilustrar o funcionamento do BGP sem os roteadores IGP. A única diferença é que os prefixos associados a cada AS precisam ser configurados manualmente, ao invés de serem criados automaticamente via OSPF. Observe na figura, que os AS2 e AS3 se comunicarão com o AS1 através de um IXP (ponto de troca), representado pela interface da espec. Não existe comunicação direta entre os AS2 e AS3. Isto significa que não há acordo de troca de tráfego entre eles.

4 BGP: Criação do Cenário (passo1: criação das VMs) / /24 AS2 VM2 eth /8 AS1 VM /24 AS3 VM3 Ponto de Troca (IXP/ PTT) /8 Código estudante: (101) X eth /8 1) Preparação do roteador VM1: 1.a) NA ESPEC. Crie uma pasta no seu diretório e inicialize a máquina virtual VM1 > mkdir quagga > cd quagga > linux32.redes VM1 1.b) NA VM1. Configure o endereço IP e instale o pacote quagga: > ifconfig /8 > wget /~jamhour/pacotes/quagga_rpm.tar.gz > tar -xzf quagga <TAB> > cd quagga <TAB> >./install.sh 2) Preparação do roteador VM2: 2.a) NA ESPEC. Inicialize uma máquina virtual com o nome VM2 > linux32.redes VM2 2.b) NA VM2. Configure o endereço IP e instale o pacote quagga: > ifconfig /8 > wget /~jamhour/pacotes/quagga_rpm.tar.gz > tar -xzf quagga <TAB> > cd quagga <TAB> >./install.sh 3) Preparação do roteador VM3: 3.a) NA ESPEC. Inicialize uma máquina virtual com o nome VM3 > linux32.redes VM3 3.b) NA VM3. Configure o endereço IP e instale o pacote quagga: > ifconfig /8 > wget /~jamhour/pacotes/quagga_rpm.tar.gz > tar -xzf quagga <TAB> > cd quagga <TAB> >./install.sh

5 BGP: Configuração (passo 2: inicializar o Zebra) Exemplo de arquivo de configuração do zebra hostname VM1 password zebra enable password zebra Descrição das interfaces interface lo Interface de loopback interface sit0 Interface com suporte a multicast Rota default estática ip route / log file zebra.log /etc/quagga/zebra.conf.sample 2) Inicializar e Testar o Zebra Após a instalação do quagga, um arquivo modelo para cada programa é criado no diretório /etc/quagga. O arquivo modelo para o zebra está ilustrado na figura acima. As linhas que começam com são comentários. No arquivo modelo, apenas as linhas que dão o nome ao roteador e definem a senha de acesso via telnet não estão comentadas. 2.a) Na VM1: inicialize o zebra service zebra status (* verifique se o zebra está sendo executado *) service zebra stop (* paralise o serviço caso ele já esteja rodando *) cd /etc/quagga zebra d f zebra.conf.sample OBS. É conveniente re-inicializar o serviço zebra para garantir que o arquivo de inicialização utilizado é o zebra.conf.sample. O arquivo de inicialização default (zebra.conf) não possui senha, o que desabilita o acesso via telnet. 2.b) Na VM2: inicialize o zebra service zebra status (* verifique se o zebra está sendo executado *) service zebra stop (* paralise o serviço caso ele já esteja rodando *) cd /etc/quagga zebra d f zebra.conf.sample 2.c) Na VM3: inicialize o zebra service zebra status (* verifique se o zebra está sendo executado *) service zebra stop (* paralise o serviço caso ele já esteja rodando *) cd /etc/quagga zebra d f zebra.conf.sample

6 BGP: Configuração (passo 3: inicializar bgpd) CONFIGURAÇÃO DA VM1 hostname bgpd password zebra log stdout router bgp 1 bgp router-id network /24 neighbor remote-as 2 neighbor next-hop-self neighbor remote-as 3 neighbor next-hop-self line vty Não esqueça de trocar os endereços IP de acordo com o seu código estudante. Nos exemplos o código de estudante adotado foi: (101) X CONFIGURAÇÃO DA VM2 hostname bgpd password zebra log stdout router bgp 2 bgp router-id network /24 neighbor remote-as 1 line vty CONFIGURAÇÃO DA VM3 hostname bgpd password zebra log stdout router bgp 3 bgp router-id network /24 neighbor remote-as 1 line vty 3) Configurar e Inicializar o BGP (ospfd) Para interpretar os arquivos de configuração mostrados na figura, é necessário olhar a figura com o cenário completo da rede na página 3. A descrição do arquivo de configuração da VM1 é feita a seguir. O arquivo das demais VMs é similar, e pode ser interpretado por analogia. A linha router bgp 1 indica que o número do AS do roteador é 1 A linha network , indica que esse AS possui esse prefixo A linha neighbor remote as 2, indica que esse AS se comunica com o roteador , que pertence ao AS2 A linha neighbor next-hop-self, indica que as rotas divulgadas para o AS2 irão apontar para o roteador VM1 como gateway. A linha neighbor remote as 3, indica que esse AS se comunica com o roteador , que pertence ao AS3 A linha neighbor next-hop-self, indica que as rotas divulgadas para o AS3 irão apontar para o roteador VM1 como gateway. 3.a) Na VM1: crie um arquivo /quagga/etc/bgpd.conf idêntico ao da figura e inicialize o bgpd cd /etc/quagga vi bgpd.conf... <INS> Copie o texto da figura sem os comentários e salve com <ESC>wq bgpd d f bgpd.conf 3.b) Na VM2: crie um arquivo /quagga/etc/bgpd.conf idêntico ao da figura e inicialize o bgpd cd /etc/quagga vi bgpd.conf... Copie o texto da figura sem os comentários e salve com <ESC>wq bgpd d f bgpd.conf 3.c) Na VM3: crie um arquivo /quagga/etc/bgpd.conf idêntico ao da figura e inicialize o bgpd cd /etc/quagga vi bgpd.conf... Copie o texto da figura sem os comentários e salve com <ESC>wq bgpd d f bgpd.conf

7 BGP: Verificação (passo 4: verificar as rotas) / /24 AS2 VM /8 AS1 VM /24 AS3 VM3 Ponto de Troca (IXP/ PTT) /8 Código estudante: (101) X /8 4.a) Na VM1: verifique e salve as rotas criadas na VM1 route n route -n > rotasas1.txt 4.b) Na VM2: verifique e salve as rotas criadas na VM2 route n route -n > rotasas2.txt 4.c) Na VM3: verifique e salve as rotas criadas na VM3 route n route -n > rotasas3.txt Não esqueça de terminar as VMs com o comando halt.

8 Relatório BGP Responda as seguintes perguntas em um arquivo txt: A) Quais as rotas que apareceram em VM1 depois do BGP B) Quais as rotas que apareceram em VM2 depois do BGP C) Quais as rotas que apareceram em VM3 depois do BGP Para entrega desse relatório, crie um arquivo texto com as respostas de A até D. Para ilustras as rotas, use a mesma sintaxe que você obteve com o comando route n. Preferencialmente, copie o texto da rotas diretamente dos arquivos criados nos passos 4a, 4b e 4c.