BGP – Confederations e Route Reflectors

FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DO PORTO

BGP – Confederations e Route Reflectors

Relatório Trabalho Prático2

Paulo Vilares, José Alexandre e Geraldo Carlos

Maio de 2010

DEPARTAMENTO DE CIÊNCIA DE COMPUTADORES

Tópicos Avançados de Redes

1

ÍNDICE

Índice ............................................................................................................................................. 1

1 Introdução ............................................................................................................................. 2

2 Objectivos .............................................................................................................................. 3

3 Border Gateway Protocol ...................................................................................................... 4

3.1 Confederations ................................................................................................................. 4

3.2 Route Reflector ................................................................................................................ 6

4 Implementação ..................................................................................................................... 7

4.1 Topologia .......................................................................................................................... 7

4.1.1 Cenário 1 – Confederations ..................................................................................... 7

4.1.2 Cenário 2 – Route Refectors .................................................................................... 8

4.2 Procedimentos ................................................................................................................. 9

4.2.1 Cenário 1 – Confederations ..................................................................................... 9

4.2.2 Cenário 2 – Route Refectors .................................................................................. 12

4.3 Ferramentas ................................................................................................................... 14

5 Resultados ........................................................................................................................... 15

5.1 Realização de Testes ...................................................................................................... 15

5.1.1 Conectividade ........................................................................................................ 15

5.1.2 Tabelas BGP ........................................................................................................... 20

5.1.3 Introdução de Novas Rotas ................................................................................... 22

5.2 Mensagens BGP .............................................................................................................. 29

6 Discussão de Resultados ..................................................................................................... 30

7 Referências .......................................................................................................................... 32

2

1 INTRODUÇÃO

Border Gateway Protocol (BGP) é o foco principal do presente relatório, e é o principal

protocolo de routing presente na internet. Como será explicada na introdução teórica, o BGP

necessita de uma estrutura full-mesh entre os diversos routers BGP dentro de um AS, e uma

estrutura deste tipo é pouco escalável, pois á medida que o número de routers aumenta o

número de sessões BGP aumenta quadraticamente. Por exemplo, se tivermos N routers o

número de sessões BGP seria de N* (N-1) /2. Como tal são necessárias alternativas que

reduzam o número de sessões. E é nessas alternativas que a implementação prática se irá

focar, nomeadamente na implementação de Confederations e de Route Reflectors.

Assim, ao longo deste trabalho, alguns conceitos atrás do BGP serão explicados e analisados.

Os conceitos e definições contidas neste trabalho são baseados nas especificações do BGP -

RFCs 1771, 3065 e 2796. Será também apresentada, analisada e discutida a implementação

prática de duas redes BGP, que foram planeadas no âmbito deste trabalho prático, assim como

a discussão de resultados obtidos. Uma tem como base a implementação de Confederations e

a outra a implementação de Route Reflectors.

3

2 OBJECTIVOS

Os objectivos propostos para o trabalho prático podem ser definidos em:

Objectivos gerais

Realizar configurações avançadas em dispositivos de rede, nomeadamente em

Routers;

Conhecer e aprender o funcionamento de novas operações em Cisco IOS.

Objectivos específicos

Configurar o protocolo BGP;

Configurar a interacção do BGP com IGPs;

Configurar BGP Route Reflectors e observar o seu funcionamento;

Configurar BGP Confederations e observar o seu funcionamento;

Confirmar processo de propagação de rotas.

4

3 BORDER GATEWAY PROTOCOL

O BGP, é um Exterior Gateway Protocol (EGP). Permite configurar um sistema de routing inter-

dominios que automáticamente garante a troca de informação de routing entre sistemas

autónomos (AS). [1] É portanto, um protocolo de routing inter-AS. Um AS é um grupo de

routers sob o mesmo domínio de administração, que utiliza um protocolo IGP como, por

exemplo, o protocolo OSPF (que foi o utilizada na implementação prática) e métricas comuns

para encaminhar pacotes dentro do mesmo AS. Um AS utiliza um protocolo EGP para

encaminhar pacotes entre ASs distintos, como o caso do BGP.

A principal função do BGP é permitir a troca de informações relacionadas com a acessibilidade

de redes (network reachability). Esta informação é uma indicação do caminho completo que

uma rota tem que percorrer para atingir um determinado destino. A partir desta troca de

informação é construído um grafo de ASs sem ciclos (loop-free) e onde é possível aplicar

politicas de routing. [1]

O BGP utiliza o protocolo TCP como protocolo de transporte. Os vizinhos BGP trocam

informação de rotas quando estabelecem pela primeira vez uma ligação TCP. Quando são

detectadas alterações na tabela de routing enviam apenas informação das rotas alteradas aos

seus vizinhos. Ao contrário de outros protocolos de routing, o BGP não envia updates

periódicos e apenas anuncia o “melhor” caminho para a rede de destino. Utiliza muitos

parâmetros de routing, denominados atributos, para definir politicas de routing e para manter

um ambiente estável. Para além dos atributos, o BGP utiliza o CIDR (Classless Interdomain

Routing) que permite uma redução significativa do tamanho das tabelas de routing.

A configuração do BGP pode revelar-se problemática em AS’s com um elevado número de

routers e manter sessões de iBGP entre eles pode revelar-se uma tarefa bastante complexa.

Para estes casos, o BGP prevê mecanismos mais escaláveis de ligar os peers iBGP. O uso de

Route Reflectors e Confederations são dois desses mecanismos. [2,3]

3.1 CONFEDERATIONS

Um AS que use confederações BGP, separa cada router presente no AS em uma ou mais

confederações (sub-AS). Os peers dentro do mesmo sub-AS são considerados confederation

iBGP peers, e os routers em diferentes sub-AS são considerados confederation eBGP peers. [2]

5

O uso de confederações 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

possível, as ligações eBGP confederation peer têm um comportamento como eBGP peers reais

em alguns aspectos. Num único sub-AS, os peers iBGP da confederação precisam de actuar em

full mesh, porque estes se comportam exactamente como iBGP peers normais, dito por outras

palavras significa que eles não anunciam as rotas iBGP entre eles. No entanto os peers eBGP

dentro de uma confederação comportam-se como eBGP peers, sendo assim estes podem

anunciar rotas iBGP aprendidas dentro da sua confederação para outra confederações (sub-

AS).

Na figura 3.1 podemos ver um exemplo do fluxo básico de uma topologia usando

confederações. É importante salientar o valor do AS_PATH conforme passa pelos diferentes AS

e respectivos sub-AS.

3.1 - Fluxo básico de uma topologia usando confederações. [4]

6

3.2 ROUTE REFLECTOR

Os route reflectors alcançam o mesmo resultado que as confederações - estes removem a

necessidade de haver full mesh entre os peers iBGP, permitindo a todas as rotas iBGP serem

aprendidas por todos os routers iBGP no AS, e prevenindo loops. Numa topologia iBGP usando

router reflectors, um mesh parcial entre peers iBGP é definido. Alguns routers são

configurados como servers de Route Reflectors, estes servers têm a capacidade de aprender

rotas iBGP dos seus clientes e depois anunciar estas mesmas rotas para outros peers iBGP. O

exemplo na figura 3.2 mostra os termos chave e alguma da lógica usada por um route

reflector, é de salientar que apenas o route reflector server usa uma lógica diferente com os

clientes e não clientes actuando como peers iBGP normais.

3.2 – Fluxo básico usando um único RR. [4]

7

4 IMPLEMENTAÇÃO

Este capítulo descreve a implementação prática da rede BGP que foi planeada no âmbito deste

trabalho prático. A implementação foi dividida em dois cenários, um correspondente à

implementação de Confederations (Cenário 1) e o outro à implementação de Route Reflectors

(Cenário 2).

4.1 TOPOLOGIA

As redes de teste criadas e configuradas para a implementação prática são compostas por

routers CISCO. Para tal, foi utilizado o GNS3 para simular as respectivas redes. Ambas as redes

são semelhantes em termos de topologia mas diferentes na sua configuração e interacção com

os diferentes dispositivos da rede.

4.1.1 CENÁRIO 1 – CONFEDERATIONS

A figura 4.1 apresenta a topologia criada para a configuração de Confederations.

8

Para este cenário dividimos os AS3 em dois sub-AS mais pequenos, AS65050 e AS65060. O

número dos sub-AS foi escolhido a partir da gama privada de números AS (64512 a 65535). OS

routers R6 e R5 têm ambos uma sessão 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 números 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.

4.1.2 CENÁRIO 2 – ROUTE REFECTORS

A figura 4.2 apresenta a topologia criada para a configuração de Route Reflector.

Neste segundo cenário, 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

constituído 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 cenário à semelhança do cenário 1 foi utilizado routing

dinâmico, nomeadamente o protocolo OSPF.

9

4.2 PROCEDIMENTOS

Esta secção, descreve os procedimentos e configurações que foram utilizados para realizar a

implementação prática, tanto no cenário 1 como no cenário 2. As configurações apresentadas

abordam só as configurações do BGP. Aspectos como a configuração de IPs dos diferentes

routers não serão apresentados, podendo ser consultados nos ficheiros em anexo.

4.2.1 CENÁRIO 1 – CONFEDERATIONS

Router R1

O router R1 tem todas as interfaces de rede na área OSPF 1. Tem uma sessão eBGP com o

router R6 (AS1) e uma sessão 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 configuração 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 sessão eBGP (confederation) com o router R3 (sub-AS65060). Tem também uma

sessão 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 estão na área 0. É importante referir

que na interface pela qual se liga ao router R3 o OSPF está configurado como passivo (passive-

interface serial 1), estando só a correr eBGP nessa ligação. A configuração utilizada foi a

seguinte:

router ospf 10 passive-interface FastEthernet 1/0

10

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 também se identifica como fazendo parte da confederação 3 (confederation

identifier 3). É utilizado o comando confederation peers 65060 para preservar todos os

atributos, como por exemplo preferências locais e o next-hop, quando passar pela sessão

eBGP para o AS65060. Isto fará com que a sessão eBGP (confederation) com o AS65060 se

comporte como uma sessão iBGP. O comando neighbor 172.16.50.1 next-hop-self define o

endereço do próximo salto das rotas enviadas do router R2 para o router R3, com os IPs das

interfaces do router R2. Sem este comando, o endereço do próximo salto de todas as rotas

eBGP do AS1 serão enviadas para o R3 com endereço externo 172.16.20.1, que só é aceitável

se os routers no sub-AS 65060 conseguirem chegar ao mesmo a partir da sua confederação.

Router R3

A mesma configuração aplica-se ao router R3, que também é 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 sub-

AS65060 são independentes das áreas 0 e 5 no sub-AS65050, estão protegidas uma da outra

pelo BGP. A configuração 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

11

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 confederação 3. Tem uma sessão eBGP com R5 no AS2.

Tem todas as interfaces na área 0 do protocolo OSPF e não está a correr o OSPF na interface

que liga com o AS2. Por este motivo o próximo salto dos updates externos, quando são

enviados para o router R4 têm de ser definidos para “self” antes de as rotas serem propagadas

para o router R3. A configuração 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 sessão eBGP com o AS1 e

outra com o AS3. E não tem conhecimento dos sub-AS na confederação 3. A configuração

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

12

O router R6 tem uma sessão eBGP com o router R1. Para o mesmo, o router R1 pertence ao

AS3, pois não tem visibilidade para os sub-AS dentro da confederação 3. Tem também uma

sessão eBGP com o router R5 situado no AS2. A configuração 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

4.2.2 CENÁRIO 2 – ROUTE REFECTORS

Router R1

Do ponto de vista do router R1, a sessão BGP com o router R2 é uma sessão iBGP normal, ou

seja, o R1 não precisa saber que é um cliente. Esta é uma característica importante na

implementação de Route Reflection, os clientes não precisam de saber que são clientes. A

configuração 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 são configurados usando o comando route-

reflector-client seguido do parâmetro neighbor x.x.x.x, onde x.x.x.x é o endereço 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 configuração utilizada foi a

seguinte:

router ospf 10 passive-interface FastEthernet 1/0 network 172.16.70.2 0.0.0.0 area 5

13

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 saída 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 configuração do router R3 é semelhante à do router R2. O router R3 é também um Route

Reflector. As diferenças são na identificação dos seus clientes, do ID do cluster e das redes a

anunciar. A configuração 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 à semelhança do R1 é também um cliente, sendo dessa forma a configuração do

router R4 semelhante à do router R2. A configuração utilizada foi a seguinte:

14

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 têm as mesmas configurações usadas no cenário anterior (cenário 1 -

confederations). Como já referido as configurações na sua totalidade podem ser consultadas

nos ficheiros em anexo.

4.3 FERRAMENTAS

Versões

BGP –version 4 (BGP-4)

Cisco IOS (router 7200) – version 12.4 (3), release software (fc2)

Ferramentas de teste e verificação

Para verificar as comunicações entre os routers e os seus parâmetros, 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 próximo capítulo analisa.

15

5 RESULTADOS

Este capítulo analisa a troca de mensagens do protocolo BGP, assim como os resultados a que

chegamos nos testes que foram realizados usando esta implementação prática. Verifica

também as tabelas BGP de alguns routers relevantes de modo a verificar as redes anunciadas.

5.1 REALIZAÇÃO DE TESTES

5.1.1 CONECTIVIDADE

Para testar as ligações e funcionamento do protocolo IGP (OSPF) entre os routers realizamos

testes de conectividade (ICMP) entre os routers do mesmo AS e entre AS diferentes.

CENÁRIO 1 – CONFEDERATIONS

Na figura 5.1 é visível a realização com sucesso do teste a todos os routers do AS3, este teste

foi realizado a partir do sub-AS65050, router R1.

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.

Router R2

Router R3

Router R4

16

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) através do AS3 e directamente entre os dois. Este era o último teste onde se prova a

ligação entre routers em AS diferentes.

Figura 5.3 - Resultado do comando ping do R5 para o router R6.

Router R1

Router R2

Router R4

Através do AS3

Entre o AS1 e o AS2 (sem passar pelo AS3)

17

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.

Figura 5.4 – Captura de pacotes ICMP na interface que liga o R5 ao AS3.

18

Figura 5.5 - Captura de pacotes ICMP na interface que liga o R5 directamente ao AS1.

CENÁRIO 2 – ROUTE REFLECTION

Foram realizados os mesmos testes para o cenário 2 e os mesmos também foram realizados

com sucesso. A Figura 5.6 apresenta o teste de ping a todos os routers do AS3, este teste foi

realizado a partir do cluster 1, router R2.

Figura 5.6 - Resultado do comando ping do R2 (cluster 1) para todos os routers do AS3.

Router R1

Router R3

Router R4

19

À semelhança do cenário 1, na figura 5.7 temos o mesmo teste efectuado anteriormente mas

agora a partir do cluster 2, router R3.

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 sessão eBGP. Para a interface interna do R6, ou seja para

a rede 192.168.10.0/24 o mesmo não acontece porque nas configurações de R6 esta rede não

está a ser anunciada pelo BGP. Esta configuração foi prepositada, de modo a verificar a

introdução de novas rotas no tópico mais abaixo (5.1.3) e testar depois a sua conectividade.

Router R1

Router R2

Router R4

20

Figura 5.8 - Resultado do comando ping do R5 (AS2) para as interfaces do R6 (AS1).

5.1.2 TABELAS BGP

Neste tópico verificamos se as rotas estão a ser anunciadas correctamente pelos routers e

como os mesmos as identificam. Para tal examinados o conteúdo das tabelas BGP, que pode

ser obtido a partir do comando show ip bgp.


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). Também podemos verificar que os sub-AS do AS3 não estão visíveis para

o R5. Indica portanto que as configurações foram realizadas com sucesso, pois o mesmo não

necessita de ter conhecimento dos sub-AS que não pertencem ao seu AS.

Interface externa de R6 que liga directamente ao AS3

Interface interna de R6, rede não anunciada no BGP

21

Figura 5.9 - Tabela BGP do router R5.

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 estão indicados em parêntesis, que

é o resultado esperado, pois está num sub-AS do AS3.

5.10 – Tabela BGP do router R1.

22


Neste cenário verificamos como estão a ser reflectidas as rotas no cluster. A imagem seguinte

mostra como o router R4 vê a rota 172.16.20.0/24, que está a ser reflectida no seu cluster.

Figura 5.11 – Tabela BGP para a rede 172.16.20.0/24 do router R4.

É 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 também transporta uma lista dos clusters

que contém os ID (identificadores) de todos os route reflectors pelos quais passou.

5.1.3 INTRODUÇÃO DE NOVAS ROTAS

Para testar as configurações do BGP, nos próximos testes a apresentar adicionamos novas

redes. Estes testes têm como finalidade mostrar se as novas redes são aprendidas pelos

routers e como as mesmas são aprendidas nos diferentes AS.


No caso do cenário 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 configuração):

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 anúncio da nova

rede, respectiva rota e que a mesma vem do AS1.

23

Figura 5.12 – Tabela BGP do router R1 após adicionar a nova rede.

Podemos verificar e confirmar os mesmos atributos na figura 5.12, que apresenta uma captura

na interface do R1 após adicionarmos a nova rede, na qual identificamos o pacote respectivo à

mensagem BGP Update da rede referida.

Figura 5.13 – Captura na interface de R1 após adicionar a nova rede.

A partir do AS1

24

Para verificarmos o anúncio 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 sub-

AS65050 apresentado em parêntesis, e o “verdadeiro” AS 1 apresentado fora do parêntesis.

Figura 5.14 - Tabela BGP do router R4 após adicionar a nova rede.

Podemos também verificar e confirmar na figura 5.14 os atributos da mensagem update

capturada após adicionarmos a nova rede.

25

Figura 5.15 - Captura na interface de R4 após adicionar a nova rede.

Para verificar se o AS2 recebeu o anúncio 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 inclusão dos sub-AS já não está presente, mesmo quando o caminho é a partir do R4.

Apenas são mostrados os AS principais.

Figura 5.16 - Tabela BGP do router R5 após adicionar a nova rede.

Sub-AS65050 e AS de origem AS1

26


Como referido anteriormente no tópico 5.1.1, o router R6 não está configurado para anunciar

a rede 192.168.10.0/24. O mesmo foi propositado de modo a verificarmos agora, nos próximos

testes, a introdução dessa rede nos anúncios BGP do router R6. Os comandos utilizados para

adicionarmos a rede foram os seguintes:

ip route 192.168.10.0 255.255.255.0 172.16.20.1 router bgp 1 network 192.168.10.0 No caso do cenário 2, será apresentado apenas resultados de dois routers, R3 e R4, pois a

partir deles é possível tirar todas as conclusões necessárias para verificar e analisar a

propagação de novas redes e respectivas rotas.

A figura seguinte (figura 5.16) mostra com sucesso que o router R3 recebeu o anúncio da nova

rede (a partir do comando show ip bgp 192.168.10.0), a qual foi aprendida pelo router R1,

enviada por iBGP ao router R2 (Route Reflector) e depois reflectida para o router R3.


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

AS_PATH

27

1). Podemos verificar e confirmar na figura 5.17 os atributos a partir da mensagem update

capturada (R3) após adicionarmos a nova rede.

Figura 5.18 - Captura da mensagem update na interface de R3 após 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 diferenças 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).

AS1

28


Na figura seguinte, podemos verificar e confirmar os atributos a partir da mensagem update

capturada (R4) após adicionarmos a nova rede.

Figura 5.20 - Captura da mensagem update na interface de R4 após adicionar a nova rede.

29

5.2 MENSAGENS BGP

Ao ser demonstrada toda a parte de teste de ligações e configurações, fica a faltar uma análise

ao tráfego BGP que pela rede circula. Para tal utilizando o wireshark realizamos uma captura

durante um determinado tempo para posteriormente filtrando o desejado, analisar melhor o

tráfego BGP.

A figura 5.21 apresentada a seguir ilustra as mensagens do protocolo BGP, esta figura é

bastante importante pois são visíveis os tipos de mensagens que o protocolo BGP utiliza

(Open, Update, Keep-Alive e Notification) com excepção da mensagem Notification. A mesma

não aparece pois este tipo de mensagem só é enviada quando algum problema é detectado

numa sessão BGP.

5.21 – Mensagens BGP.

30

6 DISCUSSÃO DE RESULTADOS

Analisando os resultados obtidos podemos concluir que as configurações realizadas, em ambos

os cenários, foram bem sucedidas. Desde a verificação de conectividade entre os diversos

routers, onde verificamos que existia conectividade para as redes anunciadas pelo BGP, e a

não existência de conectividade para as redes não anunciadas, como o caso da rede

192.168.10.0/24. A análise das tabelas BGP de alguns routers mostraram o esperado,

concretamente no cenário 1 verificamos nas tabelas BGP a indicação no AS_PATH dos sub-AS

pelos quais a rota passava (para o caso do AS3) e a não inclusão desses mesmos sub-AS nas

tabelas dos routers que não faziam parte do AS3. Pois como referido no trabalho, esses

routers não têm conhecimento da existência de sub-AS dentro do AS principal. No caso do

cenário 2, a análise das tabelas BGP indicaram correctamente as rotas aprendidas. Verificamos

a inclusão dos clusters IDs (lista de clusters) pelos quais a rota passava, e a identificação do

originador da rota.

Achamos que os resultados mais relevantes foram os obtidos quando adicionamos novas rotas

nos diferentes cenários. Esses resultados permitiram-nos verificar o fluxo do anúncio de novas

rotas de acordo com o cenário. No caso do cenário 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 não há alteração do

AS_PATH (mensagem update);

6. R4 anuncia o novo prefixo ao R5 com AS_PATH 3 1, ou seja indicação dos AS principais

(mensagem update);

7. R5 também recebeu o anúncio do novo prefixo via o AS1.

No caso do cenário 2, também concluímos 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);

31

3. R2 (route reflector) ao receber o novo prefixo a partir de um cliente seu, reflecte o

anúncio via iBGP para o R3 com a inclusão do seu Cluster na lista de cluster (1);

4. R3 (route reflector) reflecte o anúncio ao R4 (com a inclusão do cluster 2) que é um

cliente Route Reflector.

Para concluir, consideramos que a configuração de confederações e route reflector trás

algumas dificuldades no inicio mas depois de estabelecidas as respectivas confederações e

route reflectors, a inclusão de novos routers torna-se mais simples, além de permitir uma

maior escalabilidade, não possível numa topologia do tipo full-mesh.

32

7 REFERÊNCIAS

[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.

http://www.faqs.org/rfcs/rfc1771.html

BGP – Confederations e Route Reflectors

Documents

Transcript of BGP – Confederations e Route Reflectors