Beruflich Dokumente
Kultur Dokumente
Maio de 2010
NDICE
ndice ............................................................................................................................................. 1 1 2 3 Introduo ............................................................................................................................. 2 Objectivos.............................................................................................................................. 3 Border Gateway Protocol ...................................................................................................... 4 3.1 Confederations ................................................................................................................. 4 3.2 Route Reflector ................................................................................................................ 6 4 Implementao ..................................................................................................................... 7 4.1 Topologia .......................................................................................................................... 7 4.1.1 4.1.2 Cenrio 1 Confederations ..................................................................................... 7 Cenrio 2 Route Refectors .................................................................................... 8
4.2 Procedimentos ................................................................................................................. 9 4.2.1 4.2.2 Cenrio 1 Confederations ..................................................................................... 9 Cenrio 2 Route Refectors .................................................................................. 12
4.3 Ferramentas ................................................................................................................... 14 5 Resultados ........................................................................................................................... 15 5.1 Realizao de Testes ...................................................................................................... 15 5.1.1 5.1.2 5.1.3 Conectividade ........................................................................................................ 15 Tabelas BGP ........................................................................................................... 20 Introduo de Novas Rotas ................................................................................... 22
1 INTRODUO
Border Gateway Protocol (BGP) o foco principal do presente relatrio, e o principal protocolo de routing presente na internet. Como ser explicada na introduo terica, o BGP necessita de uma estrutura full-mesh entre os diversos routers BGP dentro de um AS, e uma estrutura deste tipo pouco escalvel, pois medida que o nmero de routers aumenta o nmero de sesses BGP aumenta quadraticamente. Por exemplo, se tivermos N routers o nmero de sesses BGP seria de N* (N-1) /2. Como tal so necessrias alternativas que reduzam o nmero de sesses. E nessas alternativas que a implementao prtica se ir focar, nomeadamente na implementao de Confederations e de Route Reflectors. Assim, ao longo deste trabalho, alguns conceitos atrs do BGP sero explicados e analisados. Os conceitos e definies contidas neste trabalho so baseados nas especificaes do BGP RFCs 1771, 3065 e 2796. Ser tambm apresentada, analisada e discutida a implementao prtica de duas redes BGP, que foram planeadas no mbito deste trabalho prtico, assim como a discusso de resultados obtidos. Uma tem como base a implementao de Confederations e a outra a implementao de Route Reflectors.
2 OBJECTIVOS
Os objectivos propostos para o trabalho prtico podem ser definidos em: Objectivos gerais Realizar configuraes avanadas em dispositivos de rede, nomeadamente em Routers;
Objectivos especficos Configurar o protocolo BGP; Configurar a interaco do BGP com IGPs; Configurar BGP Route Reflectors e observar o seu funcionamento; Configurar BGP Confederations e observar o seu funcionamento; Confirmar processo de propagao de rotas.
3.1 CONFEDERATIONS
Um AS que use confederaes BGP, separa cada router presente no AS em uma ou mais confederaes (sub-AS). Os peers dentro do mesmo sub-AS so considerados confederation iBGP peers, e os routers em diferentes sub-AS so considerados confederation eBGP peers. [2]
O uso de confederaes permite propagar as rotas para todos os routers, sem necessitar de uma topologia full mesh entre os peers dentro de um determinado AS. Para que isto seja possvel, as ligaes eBGP confederation peer tm um comportamento como eBGP peers reais em alguns aspectos. Num nico sub-AS, os peers iBGP da confederao precisam de actuar em full mesh, porque estes se comportam exactamente como iBGP peers normais, dito por outras palavras significa que eles no anunciam as rotas iBGP entre eles. No entanto os peers eBGP dentro de uma confederao comportam-se como eBGP peers, sendo assim estes podem anunciar rotas iBGP aprendidas dentro da sua confederao para outra confederaes (subAS). Na figura 3.1 podemos ver um exemplo do fluxo bsico de uma topologia usando confederaes. importante salientar o valor do AS_PATH conforme passa pelos diferentes AS e respectivos sub-AS.
4 IMPLEMENTAO
Este captulo descreve a implementao prtica da rede BGP que foi planeada no mbito deste trabalho prtico. A implementao foi dividida em dois cenrios, um correspondente implementao de Confederations (Cenrio 1) e o outro implementao de Route Reflectors (Cenrio 2).
4.1 TOPOLOGIA
As redes de teste criadas e configuradas para a implementao prtica so compostas por routers CISCO. Para tal, foi utilizado o GNS3 para simular as respectivas redes. Ambas as redes so semelhantes em termos de topologia mas diferentes na sua configurao e interaco com os diferentes dispositivos da rede.
Para este cenrio dividimos os AS3 em dois sub-AS mais pequenos, AS65050 e AS65060. O nmero dos sub-AS foi escolhido a partir da gama privada de nmeros AS (64512 a 65535). OS routers R6 e R5 tm ambos uma sesso eBGP com o AS3 e uma entre si. usado o protocolo OSPF como IGP em cada sub-AS. O protocolo OSPF no AS65050 est a correr independentemente do protocolo OSPF do AS65060, o que significa que os nmeros das reas OSPF podem ser os mesmos nos dois sub-AS. Tiramos assim proveito de uma vantagem do BGP, nomeadamente que IGPs de um AS correm independentemente dos IGPs noutros AS.
Neste segundo cenrio, alteramos o AS3 de modo a demonstrar o uso de Route Reflectors e Peer Groups. O AS3 foi dividido em dois Clusters, cada um com um Route Reflector. Um constitudo pelos routers R1 e R2 e outro pelos routers RT3 e RT4. Os routers RT3 e RT3 fazem parte de um peer group chamado REFLECTORS e os restantes routers de cada cluster pertencem a um peer group chamado CLIENTES (independentes a cada cluster), onde politicas comuns podem ser aplicadas. Neste cenrio semelhana do cenrio 1 foi utilizado routing dinmico, nomeadamente o protocolo OSPF.
4.2 PROCEDIMENTOS
Esta seco, descreve os procedimentos e configuraes que foram utilizados para realizar a implementao prtica, tanto no cenrio 1 como no cenrio 2. As configuraes apresentadas abordam s as configuraes do BGP. Aspectos como a configurao de IPs dos diferentes routers no sero apresentados, podendo ser consultados nos ficheiros em anexo.
O router R1 tem todas as interfaces de rede na rea OSPF 1. Tem uma sesso eBGP com o router R6 (AS1) e uma sesso iBGP com o router R2 (sub-AS65050). importante referir o uso do comando bgp confederation identifier 3, que tem como objectivo permitir que o router R1 se apresente ao router R6 como parte do AS3. A configurao utilizada foi a seguinte: router ospf 10 passive-interface FastEthernet 1/0 network 172.16.0.0 0.0.255.255 area 5 network 1.1.1.1 0.0.0.0 area 5 router bgp 65050 no synchronization bgp router-id 1.1.1.1 bgp confederation identifier 3 network 172.16.20.0 mask 255.255.255.0 network 172.16.70.0 mask 255.255.255.0 neighbor 172.16.20.1 remote-as 1 neighbor 172.16.70.2 remote-as 65050 no auto-summary Router R2
O router R2 um elemento muito importante, pois o border router do sub-AS65050 que est a correr uma sesso eBGP (confederation) com o router R3 (sub-AS65060). Tem tambm uma sesso iBGP com o router R1. Tem configurado o OSPF como protocolo IGP, tendo uma rea comum com o router R1 (rea 1) e as restantes interfaces esto na rea 0. importante referir que na interface pela qual se liga ao router R3 o OSPF est configurado como passivo (passiveinterface serial 1), estando s a correr eBGP nessa ligao. A configurao utilizada foi a seguinte: router ospf 10 passive-interface FastEthernet 1/0
network 172.16.70.2 0.0.0.0 area 5 network 172.16.0.0 0.0.255.255 area 0 network 2.2.2.2 0.0.0.0 area 0 router bgp 65050 no synchronization bgp router-id 2.2.2.2 bgp confederation identifier 3 bgp confederation peers 65060 network 172.16.50.0 mask 255.255.255.0 network 172.16.70.0 mask 255.255.255.0 neighbor 172.16.50.1 remote-as 65060 neighbor 172.16.50.1 next-hop-self neighbor 172.16.70.1 remote-as 65050 no auto-summary O router R2 tambm se identifica como fazendo parte da confederao 3 (confederation identifier 3). utilizado o comando confederation peers 65060 para preservar todos os atributos, como por exemplo preferncias locais e o next-hop, quando passar pela sesso eBGP para o AS65060. Isto far com que a sesso eBGP (confederation) com o AS65060 se comporte como uma sesso iBGP. O comando neighbor 172.16.50.1 next-hop-self define o endereo do prximo salto das rotas enviadas do router R2 para o router R3, com os IPs das interfaces do router R2. Sem este comando, o endereo do prximo salto de todas as rotas eBGP do AS1 sero enviadas para o R3 com endereo externo 172.16.20.1, que s aceitvel se os routers no sub-AS 65060 conseguirem chegar ao mesmo a partir da sua confederao. Router R3
A mesma configurao aplica-se ao router R3, que tambm um border router, neste caso do sub-AS65060, assim como das reas 0 e 5 do OSPF. Como j referido as reas 0 e 5 no subAS65060 so independentes das reas 0 e 5 no sub-AS65050, esto protegidas uma da outra pelo BGP. A configurao utilizada foi a seguinte: router ospf 10 passive-interface FastEthernet 1/0 network 172.16.30.1 0.0.0.0 area 5 network 172.16.0.0 0.0.255.255 area 0 network 3.3.3.3 0.0.0.0 area 0 router bgp 65060 no synchronization bgp router-id 3.3.3.3 bgp confederation identifier 3 bgp confederation peers 65050 neighbor SUB_AS_65060 peer-group neighbor SUB_AS_65060 remote-as 65060
10
network 172.16.50.0 mask 255.255.255.0 network 172.16.30.0 mask 255.255.255.0 neighbor 172.16.30.2 peer-group SUB_AS_65060 neighbor 172.16.50.2 remote-as 65050 neighbor 172.16.50.2 next-hop-self no auto-summary
Router R4
O router R4 um border router da confederao 3. Tem uma sesso eBGP com R5 no AS2. Tem todas as interfaces na rea 0 do protocolo OSPF e no est a correr o OSPF na interface que liga com o AS2. Por este motivo o prximo salto dos updates externos, quando so enviados para o router R4 tm de ser definidos para self antes de as rotas serem propagadas para o router R3. A configurao utilizada foi a seguinte: router ospf 10 network 172.16.0.0 0.0.255.255 area 5 network 4.4.4.4 0.0.0.0 area 5 router bgp 65060 no synchronization bgp router-id 4.4.4.4 bgp confederation identifier 3 network 192.168.20.0 mask 255.255.255.0 network 172.16.30.0 mask 255.255.255.0 neighbor 172.16.30.1 remote-as 65060 neighbor 172.16.30.1 next-hop-self neighbor 192.168.20.2 remote-as 2 no auto-summary Router R5
Por ltimo, o router R5 um BGP border router do AS2. Tem uma sesso eBGP com o AS1 e outra com o AS3. E no tem conhecimento dos sub-AS na confederao 3. A configurao utilizada foi a seguinte: router bgp 2 bgp router-id 5.5.5.5 neighbor 192.168.10.2 remote-as 1 neighbor 192.168.20.1 remote-as 3 no auto-summary Router R6
11
O router R6 tem uma sesso eBGP com o router R1. Para o mesmo, o router R1 pertence ao AS3, pois no tem visibilidade para os sub-AS dentro da confederao 3. Tem tambm uma sesso eBGP com o router R5 situado no AS2. A configurao utilizada foi a seguinte: router bgp 1 network 192.68.11.0 neighbor 172.16.20.2 remote-as 3 neighbor 192.68.6.1 remote-as 2 no auto-summary
Do ponto de vista do router R1, a sesso BGP com o router R2 uma sesso iBGP normal, ou seja, o R1 no precisa saber que um cliente. Esta uma caracterstica importante na implementao de Route Reflection, os clientes no precisam de saber que so clientes. A configurao utilizada foi a seguinte: router ospf 10 passive-interface FastEthernet 1/0 network 172.16.0.0 0.0.255.255 area 5 network 1.1.1.1 0.0.0.0 area 5 router bgp 3 no synchronization network 172.16.70.0 mask 255.255.255.0 network 172.16.20.0 mask 255.255.255.0 neighbor 172.16.20.1 remote-as 1 neighbor 172.16.70.2 remote-as 3 neighbor 172.16.70.2 next-hop-self no auto-summary Router R2
O router R2 um router reflector. Os seus clientes so configurados usando o comando routereflector-client seguido do parmetro neighbor x.x.x.x, onde x.x.x.x o endereo IP do router vizinho (cliente). O comando bgp cluster-id 1 utilizado para identificar o cluster, e cada cluster tem de ter um identificar nico de modo a evitar loops. A configurao utilizada foi a seguinte: router ospf 10 passive-interface FastEthernet 1/0 network 172.16.70.2 0.0.0.0 area 5
12
network 172.16.0.0 0.0.255.255 area 0 network 2.2.2.2 0.0.0.0 area 0 router bgp 3 no synchronization bgp router-id 2.2.2.2 network 172.16.50.0 mask 255.255.255.0 network 172.16.70.0 mask 255.255.255.0 neighbor 172.16.50.1 remote-as 3 neighbor 172.16.70.1 remote-as 3 neighbor 172.16.70.1 route-reflector-client bgp cluster-id 1 no auto-summary Como o router R2 fornece o nico caminho interno de sada do cluster, o router R1 est configurado como cliente do router R2 que est configurado como Route Reflector. Juntos formam um cluster, neste caso com o ID 1000. Router R3
A configurao do router R3 semelhante do router R2. O router R3 tambm um Route Reflector. As diferenas so na identificao dos seus clientes, do ID do cluster e das redes a anunciar. A configurao utilizada foi a seguinte: router ospf 10 passive-interface FastEthernet 1/0 network 172.16.30.1 0.0.0.0 area 5 network 172.16.0.0 0.0.255.255 area 0 network 3.3.3.3 0.0.0.0 area 0 router bgp 3 no synchronization bgp router-id 3.3.3.3 network 172.16.50.0 mask 255.255.255.0 network 172.16.30.0 mask 255.255.255.0 neighbor REFLECTORS peer-group neighbor REFLECTORS remote-as 3 neighbor CLIENTS peer-group neighbor CLIENTS remote-as 3 neighbor CLIENTS route-reflector-client neighbor 172.16.30.2 peer-group CLIENTS neighbor 172.16.50.2 peer-group REFLECTORS bgp cluster-id 2 no auto-summary Router R4
O router R4 semelhana do R1 tambm um cliente, sendo dessa forma a configurao do router R4 semelhante do router R2. A configurao utilizada foi a seguinte:
13
router ospf 10 network 172.16.0.0 0.0.255.255 area 5 network 4.4.4.4 0.0.0.0 area 5 router bgp 3 no synchronization bgp router-id 4.4.4.4 network 172.16.30.0 mask 255.255.255.0 network 192.168.20.0 mask 255.255.255.0 neighbor 172.16.30.1 remote-as 3 neighbor 172.16.30.1 next-hop-self neighbor 192.168.20.2 remote-as 2 no auto-summary Router R5 e R6
Os routers R6 e R5 tm as mesmas configuraes usadas no cenrio anterior (cenrio 1 confederations). Como j referido as configuraes na sua totalidade podem ser consultadas nos ficheiros em anexo.
4.3 FERRAMENTAS
Verses BGP version 4 (BGP-4) Cisco IOS (router 7200) version 12.4 (3), release software (fc2)
Ferramentas de teste e verificao Para verificar as comunicaes entre os routers e os seus parmetros, foram utilizadas as seguintes ferramentas: WireShark software open-source que permite a captura e analise de todos os pacotes que passam uma interface de rede. Foi usado para capturar todas as mensagens que o prximo captulo analisa.
14
5 RESULTADOS
Este captulo analisa a troca de mensagens do protocolo BGP, assim como os resultados a que chegamos nos testes que foram realizados usando esta implementao prtica. Verifica tambm as tabelas BGP de alguns routers relevantes de modo a verificar as redes anunciadas.
CENRIO 1 CONFEDERATIONS
Na figura 5.1 visvel a realizao com sucesso do teste a todos os routers do AS3, este teste foi realizado a partir do sub-AS65050, router R1.
Router R2
Router R3
Router R4
Figura 5.1 Resultado do comando ping do R1 (sub-AS65050) para todos os routers do AS3.
Na figura seguinte (figura 5.2) temos o mesmo teste efectuado anteriormente, agora a partir do sub-AS65060, router R3.
15
Router R1
Router R2
Router R4
Figura 5.2 - Resultado do comando ping do R3 (sub-AS65060) para todos os routers do AS3.
A figura 5.3 monstra um teste realizado com sucesso do Router R5 (AS1) para o Router R6 (AS2) atravs do AS3 e directamente entre os dois. Este era o ltimo teste onde se prova a ligao entre routers em AS diferentes.
Atravs do AS3
16
As duas capturas apresentadas a seguir, mostram os pacotes ICMP do comando ping realizado no teste anterior. A primeira, figura 5.4, foi realizada na interface FastEthernet 1/0 do router R5 (interface ligada ao AS3), para verificar se os pacotes ICMP seguiam pelo AS3, o que comprova o mesmo. A segunda, figura 5.5, foi realizada na interface FastEthernet 1/1 do router R5 para verificar neste caso se os pacotes ICMP seguiam directamente para o AS1. Estas capturas servem para verificar se os pings anteriormente testados seguiram os caminhos previstos.
17
Figura 5.5 - Captura de pacotes ICMP na interface que liga o R5 directamente ao AS1.
Router R1
Router R3
Router R4
Figura 5.6 - Resultado do comando ping do R2 (cluster 1) para todos os routers do AS3.
18
semelhana do cenrio 1, na figura 5.7 temos o mesmo teste efectuado anteriormente mas agora a partir do cluster 2, router R3.
Router R1
Router R2
Router R4
Figura 5.7 - Resultado do comando ping do R3 (cluster 2) para todos os routers do AS3.
Por fim, a figura 5.8 monstra um teste realizado com sucesso do Router R5 (AS2) para o Router R6 (AS1) via AS3. Mas o sucesso do teste s para a interface do R6 que liga directamente o AS3 (172.16.20.1) na qual existe uma sesso eBGP. Para a interface interna do R6, ou seja para a rede 192.168.10.0/24 o mesmo no acontece porque nas configuraes de R6 esta rede no est a ser anunciada pelo BGP. Esta configurao foi prepositada, de modo a verificar a introduo de novas rotas no tpico mais abaixo (5.1.3) e testar depois a sua conectividade.
19
CENRIO 1 CONFEDERATIONS
A figura seguinte apresenta a tabela BGP do router R5, na qual podemos verificar que o router R5 v todas as rotas a partir de dois caminhos, um pelo AS1 (identificador 1) e outro pelo AS3 (identificador 3). Tambm podemos verificar que os sub-AS do AS3 no esto visveis para o R5. Indica portanto que as configuraes foram realizadas com sucesso, pois o mesmo no necessita de ter conhecimento dos sub-AS que no pertencem ao seu AS.
20
Olhando agora para a figura 5.10, que apresenta a tabela BGP do router R1, podemos observar que o router R1 consegue ver os sub-AS e que os mesmos esto indicados em parntesis, que o resultado esperado, pois est num sub-AS do AS3.
21
importante salientar como o router R4 v o originador da rota 172.16.20.0/24 (Originator) como 1.1.1.1, que o Router ID do router R1. A rota tambm transporta uma lista dos clusters que contm os ID (identificadores) de todos os route reflectors pelos quais passou.
CENRIO 1 CONFEDERATIONS
No caso do cenrio 1 introduzimos a rede 20.0.0.0/8 no R6 (AS1) e anunciamos a mesma no BGP. Os comandos utilizados foram os seguintes (no modo de configurao): ip route 20.0.0.0 255.0.0.0 172.16.20.2 router bgp 1 network 20.0.0.0
A figura seguinte (figura 5.11) mostra com sucesso que o router R1 recebeu o anncio da nova rede, respectiva rota e que a mesma vem do AS1.
22
Podemos verificar e confirmar os mesmos atributos na figura 5.12, que apresenta uma captura na interface do R1 aps adicionarmos a nova rede, na qual identificamos o pacote respectivo mensagem BGP Update da rede referida.
A partir do AS1
23
Para verificarmos o anncio da nova rede no sub-AS65060, a figura 5.13 apresenta o resultado da tabela BGP do router R4. Como podemos observar o router R4 recebeu a rede com o subAS65050 apresentado em parntesis, e o verdadeiro AS 1 apresentado fora do parntesis.
Podemos tambm verificar e confirmar na figura 5.14 os atributos da mensagem update capturada aps adicionarmos a nova rede.
24
Para verificar se o AS2 recebeu o anncio da rede, executamos o mesmo teste no R5. A figura 5.15 apresenta esse mesmo resultado. E como podemos verificar, a tabela BGP de R5 mostra que recebeu o update a partir do router R4 (AS3) e a partir do R6 (AS1). importante salientar que a incluso dos sub-AS j no est presente, mesmo quando o caminho a partir do R4. Apenas so mostrados os AS principais.
25
AS_PATH
Podemos observar na figura AS_PATH com valor 1, o ID do originador da rota (1.1.1.1), o vizinho iBGP pelo qual aprendeu a rota (2.2.2.2) e a lista de clusters pela qual passou (cluster
26
1). Podemos verificar e confirmar na figura 5.17 os atributos a partir da mensagem update capturada (R3) aps adicionarmos a nova rede.
AS1
Figura 5.18 - Captura da mensagem update na interface de R3 aps adicionar a nova rede.
Por fim, o router R9 (route reflector) reflecte a nova rede para o seu cliente (R4) como podemos observar na figura 5.18. importante salientar as diferenas quando comparado com o output do router R3, onde agora a lista de clusters inclui o cluster 2 (adicionado pelo R3) e a rota iBGP ter sido aprendida pelo router R3 (3.3.3.3).
27
Na figura seguinte, podemos verificar e confirmar os atributos a partir da mensagem update capturada (R4) aps adicionarmos a nova rede.
Figura 5.20 - Captura da mensagem update na interface de R4 aps adicionar a nova rede.
28
29
6 DISCUSSO DE RESULTADOS
Analisando os resultados obtidos podemos concluir que as configuraes realizadas, em ambos os cenrios, foram bem sucedidas. Desde a verificao de conectividade entre os diversos routers, onde verificamos que existia conectividade para as redes anunciadas pelo BGP, e a no existncia de conectividade para as redes no anunciadas, como o caso da rede 192.168.10.0/24. A anlise das tabelas BGP de alguns routers mostraram o esperado, concretamente no cenrio 1 verificamos nas tabelas BGP a indicao no AS_PATH dos sub-AS pelos quais a rota passava (para o caso do AS3) e a no incluso desses mesmos sub-AS nas tabelas dos routers que no faziam parte do AS3. Pois como referido no trabalho, esses routers no tm conhecimento da existncia de sub-AS dentro do AS principal. No caso do cenrio 2, a anlise das tabelas BGP indicaram correctamente as rotas aprendidas. Verificamos a incluso dos clusters IDs (lista de clusters) pelos quais a rota passava, e a identificao do originador da rota. Achamos que os resultados mais relevantes foram os obtidos quando adicionamos novas rotas nos diferentes cenrios. Esses resultados permitiram-nos verificar o fluxo do anncio de novas rotas de acordo com o cenrio. No caso do cenrio 1, podemos concluir o seguinte fluxo que era o esperado: 1. R6 anuncia uma nova rede 20.0.0.0/8 (mensagem update); 2. R1 aprende o novo prefixo via eBGP com AS_PATH 1; 3. R1 anuncia o novo prefixo ao R2 (mensagem update); 4. R2 anuncia o novo prefixo via eBGP ao R3 com AS_PATH (65060) 1 (mensagem update); 5. R3 anuncia o novo prefixo ao R4, que como est no mesmo sub-AS no h alterao do AS_PATH (mensagem update); 6. R4 anuncia o novo prefixo ao R5 com AS_PATH 3 1, ou seja indicao dos AS principais (mensagem update); 7. R5 tambm recebeu o anncio do novo prefixo via o AS1. No caso do cenrio 2, tambm conclumos o seguinte fluxo apresentado que era o esperado: 1. R6 anuncia uma nova rede 192.168.10.0/8 (mensagem update); 2. R1 aprende o novo prefixo com AS_PATH 1 via eBGP e anuncia-o ao R2 via iBGP (mensagem update);
30
3. R2 (route reflector) ao receber o novo prefixo a partir de um cliente seu, reflecte o anncio via iBGP para o R3 com a incluso do seu Cluster na lista de cluster (1); 4. R3 (route reflector) reflecte o anncio ao R4 (com a incluso do cluster 2) que um cliente Route Reflector. Para concluir, consideramos que a configurao de confederaes e route reflector trs algumas dificuldades no inicio mas depois de estabelecidas as respectivas confederaes e route reflectors, a incluso de novos routers torna-se mais simples, alm de permitir uma maior escalabilidade, no possvel numa topologia do tipo full-mesh.
31
7 REFERNCIAS
[1] Rekhter, Y., T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [2] P. Traina, D. McPherson, J. Scudder, Autonomous System Confederations for BGP, RFC 3065, February 2001. [3] Bates, T. e R. Chandra, BGP Route Reflection An alternative to full mesh IBGP, RFC 2796, April 2000. [4] We. Odom, J. Geier, N. Mehta, CCIE Routing and Switching Official Exam Certification Guide, 2nd Edition, Cisco Press, February 2006.
32