ISSN 1518-5974Alex Soares de Moura <asmoura@email.com>
Rede Nacional de Ensino e Pesquisa (RNP)
Resumo
1. Introdução
2. Route Map
3. Community
4. Peer Groups
5. IBGP e suas limitações
6. Route Reflector
6.1 Múltiplos RRs dentro de um cluster
6.2 Evitando loops de roteamento
7. Confederation
8. Route Flap Dampening
9. Conclusão
Referências bibliográficas
Resumo
Continuando o artigo " Dicas na Configuração do Protocolo BGP-4 - Parte 1 " veremos, neste artigo, outras características do protocolo BGP4 que são muito úteis para uso otimizado do protocolo.
1. Introdução
Neste artigo, são apresentadas características e funcionalidades do protocolo BGP-4 que são fundamentais para sua operação.
A abordagem dos tópicos neste artigo não pretende esgotar todos os aspectos possíveis de cada assunto, uma vez que o tema é extenso e complexo para ter cobertura completa neste espaço. Existem referências em forma de livros, apostilas e páginas na Internet que o leitor deve consultar a fim de obter um conhecimento mais aprofundado dos tópicos aqui abordados.
2. Route Map
Route maps servem para o BGP controlar e modificar informações de roteamento e também definir as condições da propagação de rotas entre domínios de roteamento. A sintaxe de um route map é:
route-map nome [[permit | deny] | [número-sequencial]]
O nome identifica o route map. O número-sequencial indica a posição que a instância do route map deve ter em relação a outras instâncias do mesmo route map, sendo as instâncias ordenadas seqüencialmente. Exemplos de route maps:
route-map TESTE permit 10 ! Primeiro conjunto de condições. route-map TESTE permit 20 ! Segundo conjunto de condições. (...)
Quando o BGP aplica o route map TESTE nas atualizações de roteamento (route updates), primeiro é aplicada a instância que possuir o menor número-seqüencial - no exemplo acima, a instância 10 - e depois as subseqüentes, se houver. Se o primeiro conjunto de condições não for satisfeito, o segundo é aplicado e assim por diante, até que algum conjunto de condições seja satisfeito ou quando não houver mais condições a serem aplicadas.
Os comandos match e set são usados para definir as condições no route map. O comando match define a condição a ser satisfeita e o comando set especifica a ação a ser tomada caso o update corresponda à condição. Abaixo, um exemplo de route map simples:
route-map TESTE permit 10
match ip address 10.10.8.1
set metric 10
Quando uma rota corresponder ao endereço IP 10.10.9.1, o BGP vai configurar a métrica do update para 10, propagá-lo (pelo uso da palavra-chave permit) e vai sair da lista de instâncias de route maps. Caso o update não corresponda ao critério de uma instância definida, o BGP vai comparar com a instância seguinte, até que uma ação seja tomada ou até que a última instância seja comparada. Se o update não satisfizer nenhuma das condições, o update não será propagado. Caso seja usada a palavra-chave deny na configuração do route map e o update corresponder ao critério definido, o BGP interrompe a comparação com a lista de instâncias e o update não é propagado.
Uma restrição que deve ser observada no uso de route maps é que eles podem ser usados para filtrar anúncios (redistribuição) de updates baseado em endereços IP, mas não para filtrar o recebimento de updates baseado nos endereços IP.
Abaixo, mais um exemplo de filtragem usando route map.
Figura 1 - Filtragem de rotas através de route maps
Neste exemplo, o objetivo é que o roteador B aceite somente updates de rotas pertencentes ao AS 65501, configure o valor 20 no atributo weight desses updates e rejeite os que tiverem:
No roteador B:
router bgp 65520 network 120.10.0.0 neighbor 192.168.0.2 remote-as 65501 neighbor 192.168.0.2 route-map TESTE in ! route-map TESTE permit 10 match as-path 1 set weight 20 ! route-map TESTE permit 20 match as-path 2 route-map TESTE permit 30 set weight 10 ip as-path access-list 1 permit ^65501$ ip as-path access-list 2 deny _65510_
Na configuração acima, o roteador B vai aceitar somente updates do AS 65501 com atributo AS_Path que começe e termine com 65501, ou seja, rotas originadas no AS 65501. Depois, vai configurar o valor 20 no atributo weight desses updates, rejeitar os updates que contenham o AS 65510 no AS_Path e, finalmente, configurar 10 no weight dos updates restantes, inclusive os que forem originados em outros ASs.
É possível fazer o mesmo de forma ligeiramente otimizada, usando uma expressão regular diferente na access-list 2 e economizando a configuração de um route map:
router bgp 65520 network 120.10.0.0 neighbor 192.168.0.2 remote-as 65501 neighbor 192.168.0.2 route-map TESTE in ! route-map TESTE permit 10 match as-path 1 set weight 20 ! route-map TESTE permit 20 match as-path 2 set weight 10 ! ip as-path access-list 1 permit ^65501$ ip as-path access-list 2 permit ^65520 65510 *.
Com a configuração acima se obtém o mesmo resultado da primeira configuração. No primeiro exemplo, a access-list 2 negava updates com AS_Path contendo o AS 65510. No segundo caso, o roteador B vai configurar o weight 10 em updates com AS_Path mais longos que do AS 65501 e updates originados no AS 65501 serão descartados.
3. Community
Outra forma de filtragem no BGP é a filtragem por communities. Community ("comunidade"), definida pela RFC 1997, é um grupo de destinos que tenham alguma característica em comum, que não são necessariamente um ASN ou prefixo IP específicos e sim redes que podem pertencer a qualquer AS mas, por exemplo, que fazem parte de comunidades acadêmicas ou governamentais. Assim é possível simplificar a aplicação de políticas de roteamento identificando rotas através de uma propriedade diferente do prefixo IP ou ASN daquela rota. O BGP pode usar o atributo community em conjunto com outros atributos para manipulação de rotas.
Route maps são usados para configurar o atributo community. Algumas communities pré-definidas na especificação das communities [RFC 1997] são:
| Community | Descrição |
| no-export | Não anuncie esta rota a vizinhos E-BGP. |
| no-advertise | Não anuncie esta rota a qualquer vizinho BGP. |
| internet | Anuncie esta rota para a community internet. Todos os roteadores na rede pertencem a esta community. |
Abaixo, um exemplo de configuração do atributo community usando um route map:
route-map TesteCommunity match ip address 1 set community no-advertise ! route-map ConfigCommunity match as-path 1 set community 200 additive
Usando a palavra-chave additive, o valor 200 configurado na community "TesteCommunity" vai ser adicionado ao já existente. Se não fosse usada a palavra-chave additive, a configuração substituiria o valor que já estivesse configurado na community.
Para enviar um atributo community a um vizinho BGP, deve-se usar o comando neighbor send-community, como mostrado no exemplo abaixo:
router bgp 65535 neighbor 172.16.0.2 remote-as 65520 neighbor 172.16.0.2 send-community neighbor 172.16.0.2 route-map setcommunity out
As communities podem ser usadas como argumento para filtragem no BGP. Segue um exemplo de como pode ser implementado um filtro em um roteador de forma que ele não propague route objects aprendidas de um neighbor EBGP.
Figura 2 - Filtragem de route objects usando communities
Como não desejamos que o roteador B repasse rotas aprendidas do roteador C para seus vizinhos EBGP - como o roteador A do exemplo - pode-se configurar o atributo community no-export nas rotas anunciadas pelo roteador C, como no exemplo abaixo:
No roteador C:
router bgp 65501 network 160.10.0.0 neighbor 192.168.0.1 remote-as 65520 neighbor 192.168.0.1 send-community neighbor 192.168.0.1 route-map TESTE out ! route-map TESTE permit 10 match ip address 100 set community no-export ! route-map TESTE permit 20 ! access list 100 permit 0.0.0.0 255.255.255.255
Assim, o roteador C aplica nas rotas enviadas para o roteador B o route map TESTE, que configura o atributo community no-export em todos os route updates destinados ao endereço IP 192.168.0.1, pertencente ao roteador B. O comando neighbor send-community é necessário para efetivamente incluir o atributo nas atualizações de rotas (route updates) enviados ao roteador B. Ao receber os updates do roteador C, o roteador B não vai propagá-los ao roteador A por causa do atributo community no-export configurado nas rotas recebidas.
Uma outra forma de filtragem de rotas usando o atributo community é utilizando o comando ip community-list.
No roteador C:
router bgp 65501 network 130.10.0.0 neighbor 192.168.0.1 remote-as 65520 neighbor 192.168.0.1 send-community neighbor 192.168.0.1 route-map TESTE out ! route-map TESTE permit 10 match ip address 2 set community 100 200 additive ! route-map TESTE permit 20 ! access list 2 permit 0.0.0.0 255.255.255.255
Pode-se notar que o roteador B adiciona 100 e 200 aos valores community de qualquer update enviado ao roteador C.
Para usar o comando ip community-list no roteador B para configurar o valor do atributo weight, caso o atributo community de uma rota seja 100 ou 200, pode-se usar a seguinte configuração no roteador B:
router bgp 65520 neighbor 192.168.0.2 remote-as 65501 neighbor 192.168.0.2 route-map TESTE2 in ! route-map TESTE2 permit 10 match community 1 set weight 20 ! route-map TESTE2 permit 20 match community 2 exact set weight 10 ! route-map TESTE2 permit 30 match community 3 ! ip community-list 1 permit 100 ip community-list 2 permit 200 ip community-list 3 permit internet
Qualquer rota com o atributo community com valor igual a 100 ou 200 - e, neste caso, somente 200, por causa da palavra-chave exact - corresponderá à community-list 1 ou community-list 2 e terá o atributo weight configurado com o valor 20 ou 10, respectivamente. A community-list 3 usa a palavra-chave internet permitindo que todos os outros updates sejam propagados sem alteração no valor do atributo weight, pois todas as rotas pertencem à community internet.
4. Peer Groups
Pode-se definir Peer Group como sendo um grupo de vizinhos BGP (BGP neighbors) que têm em comum as mesmas políticas. Este recurso é de grande utilidade, já que com ele é possível a um administrador definir as mesmas políticas para um grupo de roteadores ao invés de configurar cada um individualmente. Na prática, é comum administradores aplicarem um mesmo conjunto de políticas à maior parte dos peers BGP que controlam. Os peer groups também aliviam a carga de trabalho dos roteadores, que não precisam repassar as políticas para cada neighbor. Um roteador "hub" faz uma mensagem UPDATE só uma vez, baseada nas políticas do peer group, e espalha a mensagem a todos os neighbors BGP do grupo. É possível que um dos peers precise de configurações adicionais além das usadas nos outros roteadores e é possível fazer o roteador "hub" aplicar estas configurações adicionais.
É preciso observar algumas restrições no uso de peer groups com EBGP:
- O roteador "hub" - o que propaga as políticas aos outros neighbors do grupo - não pode servir de trânsito para ASs externos, ou seja, mensagens UPDATE de um neighbor EBGP em um peer group não devem ser propagadas a outros EBGP neighbors pertencentes ao mesmo peer group;
- todos os participantes de um peer group EBGP devem pertencer à mesma subrede.
Os updates são configurados por route maps, listas de distribuição e filtros. Usando a rede do exemplo abaixo, pode-se observar que o roteador A possui sessões de peering internas com os roteadores B, C e D.
Figura 3 - Exemplo de peer group
Ao invés de configurar políticas similares nos três roteadores individualmente, o roteador A pode definir um peer group que contém as políticas e aplicar o peer group aos neighbors internos usando os exemplos abaixo. A sintaxe do comando que define um peer group é:
neighbor peer-group-name peer-group
Definindo um peer group no roteador A:
router bgp 65535 neighbor PEERINTERNO peer-group neighbor PEERINTERNO remote-as 65535 neighbor PEERINTERNO route-map CONFMETRICA out ! neighbor PEERINTERNO filter-list 1 out neighbor PEERINTERNO filter-list 2 in ! neighbor 10.10.0.2 peer-group PEERINTERNO neighbor 10.10.0.3 peer-group PEERINTERNO neighbor 10.10.0.4 peer-group PEERINTERNO ! neighbor 10.10.0.2 filter-list 3 in
O exemplo define um peer group de nome PEERINTERNO e mais algumas políticas para este grupo, como o route map CONFMETRICA que configura a métrica para 5, e os filtros 1 e 2. O peer group é aplicado nos roteadores B, C e D e um filtro adicional, filtro 3, foi definido para o roteador B, que vai se sobrepor ao filtro 2 definido no peer group.
Abaixo, um exemplo de peer group usando neighbors EBGP, seguindo o diagrama da Figura 3, no roteador A.
router bgp 65535 neighbor PEEREXTERNO peer-group neighbor PEEREXTERNO route-map CONFMETRICA neighbor PEEREXTERNO filter-list 1 out neighbor PEEREXTERNO filter-list 2 in ! neighbor 192.16.10.2 remote-as 65501 neighbor 192.16.10.2 peer-group PEEREXTERNO neighbor 172.16.10.2 remote-as 65520 neighbor 172.16.10.2 peer-group PEEREXTERNO neighbor 10.10.30.2 remote-as 65530 neighbor 10.10.30.2 peer-group PEEREXTERNO ! neighbor 10.10.30.2 filter-list 3 in
É importante notar o comando remote-as antes de cada configuração de peer group. Isto é necessário porque são ASs diferentes. Neste caso, também foi aplicada uma configuração específica no roteador G.
5. IBGP e suas limitações
Como foi apresentado no artigo "O Protocolo BGP4 - Parte 1", RNP NewsGeneration (vol.3, no.2) , quando o protocolo BGP é usado internamente (IBGP) em um AS, os roteadores não anunciam rotas a outros neighbors BGP internos e torna-se necessária a configuração de sessões entre todos roteadores IBGP do AS formando uma "malha completa" (full mesh).
Figura 4 - Exemplo de full mesh IBGP
Este requisito do protocolo impõe uma limitação na escalabilidade do IBGP. A figura 4 apresenta um AS com 12 roteadores e suas respectivas sessões IBGP (linhas vermelhas) em full mesh, que são ao todo 66 ((12*11)/2) sessões. Não é difícil notar que o número de sessões cresce muito rapidamente conforme aumenta a quantidade de roteadores no AS. Caso a quantidade de roteadores seja 15, 20 e 30, são necessárias 105, 190 e 435 sessões IBGP respectivamente. Há, assim, um grande consumo de recursos escassos e igualmente não escaláveis, como a CPU e a memória dos roteadores, além da llargura de banda disponível ser utilizada de forma ineficiente.
Figura 5 - Taxa de crescimento de full meshes
Por conta deste requisito do IBGP, há uma complexidade de configuração e gerenciamento de uma grande quantidade de roteadores usando BGP em um AS, o quê torna a configuração mais suscetível a erros operacionais.
Por este motivo, foram criadas extensões para o BGP, que possibilitam o relaxamento da necessidade de full meshes mas, ainda assim, permitindo a todos os roteadores internos de um AS conhecerem todas as rotas. São duas as técnicas criadas com a finalidade de minimizar este problema de escalabilidade do IBGP: Route Reflector e Confederation.
6. Route Reflector
Um recurso elaborado para minimizar o problema do full mesh do IBGP é o Route Reflector [RFC 2796] (ou algo como Refletor de Rotas). O princípio do Route Reflector é a criação de hierarquia dentro do IBGP. Como visto anteriormente no artigo " O Protocolo BGP4 - Parte 1 ", um roteador configurado com IBGP não propaga a seus vizinhos IBGP rotas aprendidas de outro vizinho IBGP. Usando route reflection, determinados roteadores IBGP podem redistribuir rotas a vizinhos IBGP, possibilitando a todos os roteadores de um AS terem o conhecimento de todas as rotas, sem a necessidade de configuração de um full mesh IBGP.
Figura 6 - Route Reflector
Normalmente, uma full mesh de sessões IBGP deveria ser estabelecida entre os roteadores de A a I no AS 65535 do diagrama acima, mas usando o conceito de route reflector (RR), os rotadores A e B podem ser configurados como RR e ter apenas peering parcial com os roteadores C, D e E, F, G, H e I. O peering entre os roteadores C, D, E, F, G, H e I não será necessário uma vez que os roteadores A e B estarão agindo como refletores dos updates. A sintaxe do comando para configurar o route reflector (RR) é:
neighbor route-reflector-client
e os endereços IP configurados serão os dos clientes. No caso do roteador A, os route reflector clients são C e D e do RR B, os route reflector clients H e I. Esta combinação de RR e de seus respectivos route reflector clients é denominada cluster, ou seja, o A, C e D formam um cluster e B, H e I um segundo cluster (figuras 6 e 7). Outros roteadores com sessões IBGP com os RR que não são clientes são denominados non-clients. No exemplo acima, os roteadores E, F e G são non-clients dos RR A e B e por isso é necessária a configuração de uma full mesh entre eles.
Figura 7 - Route Reflector Clusters
Um AS pode ter mais de um RR e os RRs interagem entre si normalmente como um vizinho. Outros RRs podem pertencer ao mesmo cluster ou a outros clusters. Um AS pode ser dividido em vários clusters e cada RR será configurado com outros RRs como peers non-clients em uma topologia full mesh. Route reflector clients não devem estabelecer peering com roteadores IBGP fora do seu cluster.
Considerando a figura acima, os roteadores C e D formam um único cluster com o roteador A, que é o RR do cluster 1. De acordo com o roteador A, C e D são clientes e os demais são non-clients. O roteador B é o RR para seus clientes, H e I. A, B, E, F e G possuem um full mesh de sessões IBGP entre eles, mas os roteadores dentro de cada cluster não.
Um RR fará o seguinte, com uma rota recebida, dependendo do tipo de peer com quem tiver sessão estabelecida:
- Rota vindo de um peer non-client: reflete para todos os clientes dentro do cluster.
- Rota vindo de um peer cliente: reflete para todos os peers non-clients e também para os clients.
- Rota vindo de um peer EBGP: envia o update a todos os peers, clients e non-clients.
Como as rotas aprendidas são refletidas, é possível ter loops de roteamento, por isso foram implementados nos RRs métodos para evitá-los, uma vez que o BGP não pode permitir loops de roteamento:
- Originator-ID: este é um atributo do BGP criado pelo RR, que é opcional, tem 4 bytes e é do tipo não-transitivo. Este atributo contém o router-id (RID) do roteador que originou a rota no AS local. Através deste identificador, se um anúncio de rota voltar ao roteador que a originou, ele a identifica e a descarta.
- Cluster-list: veja o próximo tópico.
6.1 Múltiplos RRs dentro de um cluster
Normalmente, um cluster de clientes tem somente um RR e o cluster é identificado pelo RID do RR. Caso seja necessário uma maior redundância para evitar pontos únicos de falha, um cluster pode ter mais de um RR. Todos os RRs do mesmo cluster precisam ser configurados com um identificador do cluster (cluster-ID) com 4 bytes para que um RR reconheça updates de RRs do mesmo cluster.
Uma lista de clusters (cluster-list) é uma seqüência de cluster-IDs que a rota atravessou. Quando um RR reflete uma rota de seus clientes para non-clients fora do cluster, ele adiciona o cluster-id local no final da cluster-list. Se este update não possuir uma cluster-list, o RR criará uma. Usando este atributo, um RR pode identificar se uma informação de roteamento fez um loop e voltou ao mesmo cluster que a originou, por alguma falha de configuração. Se o cluster-id local é encontrado na cluster-list, o anúncio da rota será descartado.
Figura 8 - Mais de um route reflector no mesmo cluster
Em casos que alta disponibilidade (high availability) é imprescindível para evitar paradas do serviço por falhas, é possível a configuração de mais de um RR dentro de um mesmo cluster. Na figura acima, os roteadores F, G (RRs), K, L e M (RR clients) pertencem ao cluster 2. Observe uma redundância, pois o roteador F tem um full mesh de sessões IBGP com todos os RRs do cluster. Se o roteador F falhar, o roteador G passa a ser o RR principal do cluster.
Nas configurações acima não foram usados peer-groups. Se não há um full mesh entre os clientes de um cluster e eles trocam updates através do RR e não devem ser usados peer-groups, pois haveria grande chance de origens de rotas serem descartadas pelo RR e a falta destes route objects nos clientes do cluster causaria problemas. O sub-comando bgp client-to-client reflection é ativado por padrão no RR. Se a reflexão IBGP fosse desativada no RR e houvesse peerings redundantes entre os clientes (full mesh), seria possível o uso de peer-groups.
6.2 Evitando loops de roteamento
Existem dois atributos que ajudam a prevenir loops nas informações de roteamento: o originator-id e a cluster-list. Outra forma de controlar loops é configurando filtros nas cláusulas set de route-maps de saída (out). Esta cláusula para route-maps de propagação (out-bound route-maps) não afeta rotas refletidas aos vizinhos IBGP. Há também nexthop-self, que é mais um mecanismo de prevenção de loops. Quando usados em RRs, o comando nexthop-self afetará somente o nexthop de rotas aprendidas via EBGP porque o nexthop de rotas refletidas a vizinhos IBGP não deve ser modificado.
7. Confederation
Confederation [RFC 1997] é o grupo formado pela divisão de um AS em vários "sub-Ass". Cada sub-AS funciona de forma idêntica a um AS comum, com full mesh de sessões IBGP configuradas entre os roteadores internos e conexões para os outros sub-ASs usando EBGP, mas trocando updates como se estivessem usando IBGP, preservando as informações de next hop, métrica e local preference. De fora, a confederation é vista pelos outros ASs como sendo um único AS.
Nos roteadores Cisco, o comando para configurar uma confederation é:
bgp confederation identifier ASN
O identificador da confederation será o ASN do grupo confederado e este mesmo número será visto pelos ASs externos. Para configurar os peerings entre os sub-ASs dentro da confederation, é usado o comando:
bgp confederation peers autonomous-system [asn]
No exemplo a seguir, temos o AS 65535 com 8 roteadores usando EBGP.
Figura 9 - Exemplo de Confederation
Para configurar um full mesh IBGP dentro do AS 65535, seria necessário cada roteador ter 8 peerings configurados, sendo 7 sessões IBGP com os vizinhos internos e mais 1 peering EBGP com o vizinho do AS externo. Implementando uma confederation nesta arquitetura, pode-se dividir o AS 65535 em 3 sub-ASs: 1, 2 e 3. O mundo exterior só vai saber da existência do AS 65535. Nos ASs 1, 2 e 3 deve ser configurado internamente um full mesh de peers IBGP e também a lista de peers da confederation usando o comando bgp confederation peers. Os roteadores A, B, C, L, M, N, O e P só conhecem o AS 65535.
8. Route Flap Dampening
Route Flap Dampening, [RFC 2439] é um recurso para minimizar as instabilidades causadas por oscilações de rotas em redes (route flapping), que são geralmente provocadas por problemas em enlaces de ASs. A idéia é ter um método de identificar rotas que entram e saem das tabelas de roteamento com muita freqüência, penalizando-as para cada oscilação com um valor, por exemplo, de 1000. Quando o total de penalizações atingir um limite pré-definido de supressão (supress-limit), o roteador não fará a propagação da tal rota, suprimindo-a das tabelas de roteamento. A penalidade será decrescida exponencialmente baseado em uma "meia-vida" (half-life) - também um valor pré-definido - e quando o total de penalizações atingir o limite de reuso (reuse-limit), o anúncio da rota não será mais suprimido.
Rotas externas a um AS aprendidas via IBGP não sofrerão dampening, evitando que peers IBGP tenham penalidades maiores que as rotas externas ao AS. Nos roteadores Cisco, este recurso não está ativado por padrão, mas esta opção pode ser modificada.
9. Conclusão
Foram apresentadas neste artigo algumas caracerísticas do protocolo BGP-4 que oferecem mais flexibilidade e otimização em sua operação. Estas características permitem economias em termos de simplicidade na configuração e operação, preservam recursos como memória e CPU dos roteadores - poupando alguns milhares de dólares em equipamentos - além de proporcionarem um uso mais econômico da banda de rede disponível. Estas e outras tecnologias estão atualmente em uso nos ambientes de ISPs, NAPs, IDCs e outros operadores de redes e backbones conectados à Internet mundial.
Referências bibliográficas
[1] RFC2439 - BGP Route Flap Damping: ftp://ftp.isi.edu/in-notes/rfc2439.txt
[2] Cisco BGP Route Flap Dampening: http://www.ieng.com/warp/public/459/16.html#A24.4
[3] BGP Configuration From the IRR: http://www.isi.edu/ra/rps/training/
[4] RFC 1997 - BGP Communities Attribute: http://www.rfc-editor.org/rfc/rfc1997.txt
[5] RFC 2796 - BGP Route Reflection - An Alternative to Full Mesh IBGP: http://www.rfc-editor.org/rfc/rfc2796.txt
[6] RFC 3065 - Autonomous System Confederations for BGP: http://www.rfc-editor.org/rfc/rfc3065.txt
NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004