Olá Pessoal,
Vimos em artigos anteriores que manipular os atributos do protoclo BGP para forçar o balanceamento do tráfego de saída ou mesmo para aplicar outras políticas de engenharia de tráfego é uma ação bastante objetiva, uma vez que a origem do tráfego será algum roteador no nosso próprio AS e que, portanto, está sob nosso domínio administrativo. No entanto, é bem mais subjetiva a tarefa de balancear o tráfego de entrada que vem da Internet, já que nesse caso não temos controle sobre o tráfego entrante que está sob gestão de outras entidades externas.
Este é mais um artigo sobre configuração do protocolo BGP e novamente, por conveniência, irei me basear no laboratório 33 do livro LabCisco (2a Edição), cuja topologia adapatada pode ser observada na figura abaixo. Dessa vez o objetivo é apresentar os procedimentos necessários para dividir o prefixo da empresa em duas metades mais específicas que serão anunciadas por dois provedores (upstream) para forçar o balanceamento de tráfego de entrada.
Vamos assumir que o AS 60 possui o prefixo 198.51.16.0/21 para anunciar na Internet. Observem que o referido AS está conectado através de dois provedores (upstream), representados pelo AS 40 e AS 50. Sob a ótica do roteador R1 (no AS 123) que receberá os anúncios vindos do AS 60, o comportamento padrão do BGP é que teremos dois caminhos possíveis para alcançar o prefixo anunciado, sendo um através de R4 (vizinho eBGP) e outro através de R3 (vizinho iBGP) indo para R5 (vizinho eBGP de R3).
Os dois caminhos possíveis irão constar na tabela BGP de R1, no entanto o BGP escolherá como melhor caminho aquela rota aprendida pelo vizinho eBGP, o que fará com que todo tráfego de saída destinado ao AS 60 passe unicamente pelo AS 40. Do ponto de vista do R6 no AS 60, todo o tráfego de entrada chegará apenas através de um dos upstreams disponíveis, ou seja, sem nenhum balanceamento.
Para contornar essa limitação, é possível explorar uma característica comum dos protocolos de roteamento que sempre preferem aquelas rotas mais específicas com prefixos maiores. Por exemplo, tomando esse comportamento padrão como base, os prefixos 203.0.113.0/25 e 203.0.113.128/25 sempre serão preferidos do que a agregação deles no bloco 203.0.113.0/24. É possível utilizar essa lógica no contexto do cenário proposto e forçar o balanceamento do tráfego de entrada apenas fazendo a "quebra" do prefixo 198.51.16.0/21 em duas metades /22, ou seja, em 198.51.16.0/22 e 198.51.20.0/22. Depois de dividir o prefixo original em duas metades, o R6 deve ser configurado da forma apresentada abaixo para anunciar uma metade /22 em cada upstream, forçando o restante da Internet a buscar os destinos da empresa através de dois caminhos, ainda que de forma assimétrica em termos de carga de tráfego.
01. R6(config)# ip prefix-list to-AS40 permit 198.51.16.0/21
02. R6(config)# ip prefix-list to-AS40 permit 198.51.16.0/22
03. R6(config)# ip prefix-list to-AS50 permit 198.51.16.0/21
04. R6(config)# ip prefix-list to-AS50 permit 198.51.20.0/22
05. R6(config)# router bgp 60
06. R6(config-router)# network 198.51.16.0 mask 255.255.248.0
07. R6(config-router)# network 198.51.16.0 mask 255.255.252.0
08. R6(config-router)# network 198.51.20.0 mask 255.255.252.0
09. R6(config-router)# neighbor 10.0.6.1 remote-as 40
10. R6(config-router)# neighbor 10.0.6.1 prefix-list to-AS40 out
11. R6(config-router)# neighbor 10.0.7.1 remote-as 50
12. R6(config-router)# neighbor 10.0.7.1 prefix-list to-AS50 out
13. R6(config-router)# end
14. R6# clear ip bgp all 40 soft
15. R6# clear ip bgp all 50 soft
Depois de realizadas essas configurações em R6, é possível visualizar apenas aqueles anúncios que estão sendo enviados para os vizinhos R4 (no AS 40) e R5 (no AS 50). Observem que cada vizinho recebe apenas uma metade /22 do bloco completo /21 para forçar o balanceamento do tráfego de entrada, já que os roteadores da Internet irão optar por alcançar os destinos correspondentes à primeira metade 198.51.16.0/22 através do AS 40 e por alcançar os destinos correspondentes à segunda metade 198.51.20.0/22 através do AS 50. Observem, ainda, que para fins de disponibilidade o bloco completo /21 é anunciado para os dois upstreams, o que garante que haverá alcançabilidade a todos os destinos mesmo em caso de falha de um dos upstreams.
R6# show ip bgp neighbor 10.0.6.1 advertised-route
BGP table version is 20, local router ID is 6.6.6.6
Network Next Hop Metric LocPrf Weight Path
*> 198.51.16.0/22 0.0.0.0 0 32768 i
*> 198.51.16.0/21 0.0.0.0 0 32768 i
Total number of prefixes 2
R6# show ip bgp neighbor 10.0.7.1 advertised-route
BGP table version is 20, local router ID is 6.6.6.6
Network Next Hop Metric LocPrf Weight Path
*> 198.51.16.0/21 0.0.0.0 0 32768 i
*> 198.51.20.0/22 0.0.0.0 0 32768 i
Total number of prefixes 2
Em R2 no AS 123 é possível observar como os demais roteadores da "Internet" lidam com os anúncios que configuramos em R6. Na tabela BGP de R2 fica evidente que cada metade /22 pode ser alcançada através de diferentes caminhos, o que força o balanceamento do tráfego de entrada em R6. Também é possível observar a existência do bloco completo /21 na tabela BGP. Nesse ponto é importante lembrar que a lógica dos protocolos de roteamento dinâmico é que caminhos mais específicos sempre serão preferidos em detrimento a prefixos menores que foram agregados. Ou seja, mesmo que o bloco /21 exista na tabela BGP de R2, a preferência será por alcançar os IPs de destino a partir das rotas /22 que são mais específicas.
R2> show ip bgp
BGP table version is 30, local router ID is 2.2.2.2
Network Next Hop Metric LocPrf Weight Path
*>i198.51.16.0/22 10.0.1.1 0 100 0 40 60 i
* i198.51.16.0/21 10.0.2.2 0 100 0 50 60 i
*>i 10.0.1.1 0 100 0 40 60 i
*>i198.51.20.0/22 10.0.2.2 0 100 0 50 60 i
Façam seus testes...
Samuel.
