No Laboratório de hoje, nosso cliente fictício é um Sistema Autônomo, ou seja, possuí sua própria rede de IP pública, onde o seu ASN (Autonomous System Number) é o 500.
Topologia criada:
A rede pública deste cliente é a 200.200.200.0/24 (lembrando que é fictícia), e esta rede é gerenciada (é o gateway da rede) pelo Firewall Fortigate que o mesmo possuí na sua empresa.
O cliente possuí dois provedores de upstream, onde ele necessita que a sua rede pública seja anunciada para estes dois provedores para manter a disponibilidade da sua rede em caso de falha de um dos provedores. Os dois provedores irão anunciar apenas a rota default (0.0.0.0/0) para o Firewall.
O anúncio das rotas será realizado pelo Protocolo BGP (Border Gateway Protocol).
O que o cliente solicitou para configurar?
Provedor ISP-A ser o primário tanto para o tráfego de saída quanto para o tráfego de entrada.
Além da alta disponibilidade entre as operadoras, cliente também queria usufruir dos benefícios do SD-WAN no Fortigate, para obter um melhor desempenho nas suas comunicações independente de qual Provedor está como primário via BGP, pois o SD-WAN escolherá o melhor caminho baseado nas regras aplicadas e vai definir de forma inteligente o melhor Link para ser utilizado nas suas comunicações.
Como o Post está dividido?
Inicialmente, irei abordar as configurações de IP, roteamento dinâmico via BGP, como a manipulação das rotas foi realizada, e por fim uma demonstração dos testes realizados. Após, abordaremos a parte do SD-WAN.
Vamos falar um pouco sobre o BGP:
Sempre quando falamos de ASN, a troca de rotas entre provedores é realizada pelo Protocolo BGP.
Nesta topologia, cada ASN que é diretamente conectado possuí uma sessão eBGP (external Border Gateway Protocol) configurado entre eles, ou seja, uma sessão BGP entre ASN's diferentes.
O BGP possuí diversas formas de manipulação de tráfego e processo de seleção de melhor rota. Segue alguns exemplos retirados do Fórum da Fortinet:
Como o Fortigate do Cliente está recebendo apenas uma rota default (0.0.0.0/0) dos ISP's , e o mesmo deseja que o "ISP-A" seja sempre preferencial enquanto este estiver online, a manipulação das rotas ocorreram da seguinte maneira:
Para o tráfego de download: será controlado nos anúncios de out do BGP no Firewall, onde para o provedor secundário "ISP-B", a rota da rede 200.200.200.0/24 será anunciada com prepend. Conforme a Figura 2 acima, no item 4, a preferência é o caminho mais curto (shortest AS path), e quando incluímos prepend na rota, o path acaba ficando mais longo. Exemplo de um "sh ip bgp" num roteador Cisco da Topologia:
* 200.200.200.0 172.16.2.2 0 500 500 500 500 ?
*> 172.16.4.1 0 30 10 500 ?
Podemos observar que a rota recebida do 172.16.4.1 está como best route, devido ao path ser mais curto. O caminho via 172.16.2.2 está recebendo prepend de 3.
Para o tráfego de upload: será controlado nos anúncios de in do BGP no Firewall, no qual será manipulado com o uso do atributo Local Preference. Quanto maior o valor do atributo, maior a preferência sob a rota.
Topologia Física:
Cliente possuí um Firewall Fortinet, onde nas portas 1 e 2 são conectados o "ISP-A" e "ISP-B" respectivamente. A rede LAN do Firewall está conectado na porta 3. Os "ISP-A" e "ISP-B" são atendidos pelo provedor "ISP-WORLD", que simula a "rede da internet", como se fosse um grande provedor que atende ambos, onde possuem uma interface conectada diretamente entre eles. Todos os equipamentos dos ISP's são Cisco.
Topológia Lógica:
Equipamentos que são diretamente conectados possuem uma rede /30 inválida entre si, conforme demonstramos na Figura 1 da "Topologia Criada", acima. Entre eles, foi configurado sessões eBGP, para o anúncio das rotas. Na Figura 3, abaixo, demonstramos como foi configurado os anúncios das rotas BGP entre os roteadores:
Configurações Aplicadas:
Configuração no Fortigate:
Interfaces:
A rede LAN 200.200.200.1/24 foi configurado como IP Secundário na interface de Gerenciamento do Firewall, devido à VM do Firewall com Licença Evaluation ter disponível apenas 3 interfaces:
Prefix-List e Route-map:
config router prefix-list
edit "PUBLIC_LAN_PL"
config rule
edit 1
set prefix 200.200.200.0 255.255.255.0
unset ge
unset le
next
end
next
edit "DEFAULT_ROUTE_BGP"
config rule
edit 1
set prefix 0.0.0.0 0.0.0.0
unset ge
unset le
next
end
next
end
#
config router route-map
edit "PUBLIC_LAN_RM"
config rule
edit 1
set match-ip-address "PUBLIC_LAN_PL"
next
end
next
edit "PUBLIC_LAN_RM_PREPEND"
config rule
edit 1
set match-ip-address "PUBLIC_LAN_PL"
set set-aspath "500 500 500"
next
end
next
edit "DEFAULT_ROUTE_RM_ISP_A"
config rule
edit 1
set match-ip-address "DEFAULT_ROUTE_BGP"
set set-local-preference 500
next
end
next
edit "DEFAULT_ROUTE_RM_ISP_B"
config rule
edit 1
set match-ip-address "DEFAULT_ROUTE_BGP"
set set-local-preference 400
next
end
next
end
Aqui configuramos duas prefix-list, a "PUBLIC_LAN_PL" para rede 200.200.200.0/24, onde foi utilizado para a route-map do tráfego de out, e a "DEFAULT_ROUTE_BGP", para a rede default (0.0.0.0/0) recebida pelos provedores, para ser utilizado na route-map do tráfego de in.
Para a manipulação do tráfego das rotas BGP, configuramos 4 route-maps, sendo elas:
A route-map "PUBLIC_LAN_RM", no qual da match na prefix-list "PUBLIC_LAN_PL", apenas para anunciar a rede pública do cliente aos provedores. Essa route-map foi utilizada para o tráfego de out para o provedor "ISP-A";
A route-map "PUBLIC_LAN_RM_PREPEND", também da match na prefix-list "PUBLIC_LAN_PL", porém podemos observar o comando set set-aspath "500 500 500", que foi utilizado para adicionar 3 de prepend na rota. Essa route-map foi utilizada para o tráfego de out para o provedor "ISP-B";
A route-map "DEFAULT_ROUTE_RM_ISP_A", para controlar e priorizar a rota default que é recebida pelo "ISP-A", onde estamos setando um local-pref maior, conforme comando set set-local-preference 500;
A route-map "DEFAULT_ROUTE_RM_ISP_B", para controlar e priorizar a rota default que é recebida pelo "ISP-A", onde estamos setando um local-pref menor, conforme comando set set-local-preference 400.
BGP:
config router bgp
set as 500
set router-id 200.200.200.1
config neighbor
edit "172.16.1.1"
set remote-as 10
set route-map-in "DEFAULT_ROUTE_RM_ISP_A"
set route-map-out "PUBLIC_LAN_RM"
set update-source "port1"
next
edit "172.16.2.1"
set remote-as 20
set route-map-in "DEFAULT_ROUTE_RM_ISP_B"
set route-map-out "PUBLIC_LAN_RM_PREPEND"
set update-source "port2"
next
endConfiguração do BGP no Fortigate, para os dois neighbors "ISP-A" e "ISP-B" e setando as route-maps para controle dos tráfegos de in e out.
Configuração do "ISP-A":
interface Ethernet0/0
description ISP-WORLD
ip address 172.16.3.2 255.255.255.252
!
interface Ethernet0/1
description FW-PORT1
ip address 172.16.1.1 255.255.255.252
!
router bgp 10
bgp log-neighbor-changes
neighbor 172.16.1.2 remote-as 500
neighbor 172.16.3.1 remote-as 30
neighbor 172.16.3.1 description ISP-WORLD
!
address-family ipv4
redistribute connected
neighbor 172.16.1.2 activate
neighbor 172.16.1.2 route-map FW-OUT out
neighbor 172.16.3.1 activate
exit-address-family
!
ip prefix-list ANUNCIA-P-FIREWALL seq 5 permit 0.0.0.0/0
!
route-map FW-OUT permit 10
match ip address prefix-list ANUNCIA-P-FIREWALLConfiguração do "ISP-B":
interface Ethernet0/1
description ISP-WORLD
ip address 172.16.4.2 255.255.255.252
!
interface Ethernet0/2
description FW-PORT2
ip address 172.16.2.1 255.255.255.252
!
router bgp 20
bgp log-neighbor-changes
neighbor 172.16.2.2 remote-as 500
neighbor 172.16.4.1 remote-as 30
neighbor 172.16.4.1 description ISP-WORLD
!
address-family ipv4
redistribute connected
neighbor 172.16.2.2 activate
neighbor 172.16.2.2 route-map FW-OUT out
neighbor 172.16.4.1 activate
exit-address-family
!
ip prefix-list ANUNCIA-P-FIREWALL seq 5 permit 0.0.0.0/0
!
route-map FW-OUT permit 10
match ip address prefix-list ANUNCIA-P-FIREWALLPodemos observar nas configurações do "ISP-A" e "ISP-B" que não é realizado nenhum tipo de configuração para manipulação e priorização das rotas. Foi criado uma route-map "FW-OUT" para controlar o anúncio apenas da rota default ao cliente.
Configuração do "ISP-WORLD":
interface Ethernet0/0
description ISP-A
ip address 172.16.3.1 255.255.255.252
ip nat inside
ip virtual-reassembly in
!
interface Ethernet0/1
description ISP-B
ip address 172.16.4.1 255.255.255.252
ip nat inside
ip virtual-reassembly in
!
interface Ethernet0/3 <<- PORTA WAN PARA O ROUTER NAVEGAR
description WAN
ip address dhcp
ip nat outside
ip virtual-reassembly in
!
router bgp 30
bgp log-neighbor-changes
neighbor 172.16.3.2 remote-as 10
neighbor 172.16.3.2 description ISP-A
neighbor 172.16.4.2 remote-as 20
neighbor 172.16.4.2 description ISP-B
!
address-family ipv4
neighbor 172.16.3.2 activate
neighbor 172.16.3.2 default-originate
neighbor 172.16.4.2 activate
neighbor 172.16.4.2 default-originate
exit-address-family
!
ip nat inside source list 10 interface Ethernet0/3 overload
!
access-list 10 permit 200.200.200.0 0.0.0.255A configuração de NAT do "ISP-WORLD" é para conseguir demonstrar com sucesso a navegação da rede 200.200.200.0/24, onde o "ISP-WORLD" recebe o prefixo 200.200.200.0/24 de um dos ISPs e "propaga para o resto da Internet"(neste caso, apenas realiza um NAT para esta rede).
Resultados Obtidos:
Para o tráfego de download do cliente, podemos observar pelos anúncios de out do Fortigate, onde o "ISP-WORLD" está priorizando a rota da rede 200.200.200.0/24 através do "ISP-A":
Conforme Figura acima, o "ISP-WORLD" selecionou como best a rota recebida pelo 172.16.3.2 (ISP-A), pois o path é mais curto (10 500 do ISP-A contra 20 500 500 500 500 do ISP-B) devido ao prepend configurado no Fortigate nos anúncios de out para o "ISP-B".
Para o tráfego de upload, podemos observar na Figura abaixo que o Fortigate fez a seleção da best route para o 172.16.1.1 (ISP-A), devido ao valor do local preference ser maior (500 do ISP-A contra 400 do ISP-B)
Com isso, demonstramos que tanto para o tráfego de in quanto para o tráfego de out, será sempre selecionado o "ISP-A", a não ser que o mesmo fique indisponível...
Mas isso tudo pode mudar caso tivermos configurações de SD-WAN aplicadas.
Finalmente, vamos a parte do SD-WAN, conforme falamos inicialmente, o cliente quer usufruir dos benefícios do SD-WAN do Fortigate para obter um melhor desempenho nas suas comunicações independente de qual Provedor está como primário via BGP, pois o SD-WAN escolherá o melhor caminho baseado nas regras aplicadas e vai definir de forma inteligente o melhor Link para ser utilizado nas suas comunicações.
O SD-WAN possuí muitas formas de implementação e aplicabilidades, portanto, conforme o nosso LAB já está um pouco longo, vou exemplificar de uma maneira simples e direta. Pretendo futuramente realizar um LAB apenas de SD-WAN.
Configuração do SD-WAN no Firewall:
Foi criado uma Performance SLA no Fortigate, para monitorar a comunicação via ICMP para o destino 1.1.1.1, conforme imagem abaixo:
Após, foi criado uma Rule, onde o SD-WAN irá monitorar a comunicação deste IP por ambos os Link's e, conforme as configurações da Rule, o tráfego irá ser encaminhado pelo Link com melhor qualidade para este destino:
Conforme imagem acima, temos diversas opções de aplicabilidade para as Rules do SD-WAN. Poderíamos definir origens e destinos específicos, protocolos, autenticação de usuários, criar regras para desempenho de aplicações críticas, etc. O modo de seleção de interface foi selecionado como Best Quality, e o Measured SLA como "DNS", que é o nome da Performance SLA criada anteriormente. E como critério de qualidade, selecionado Packet Loss.
Como o teste foi realizado?
Para o sucesso do teste, foi configurado uma interface Loopback no "ISP-B" com o IP 1.1.1.1/32 (IP utilizado na regra "DNS" acima), para anúncio deste prefixo apenas pelo "ISP-B". Desta forma, o Fortigate não terá comunicação com o 1.1.1.1 via "ISP-A", e o SD-WAN, irá selecionar o "ISP-B" como melhor qualidade para a comunicação, por mais que o best route da rota default do Fortigate esteja pelo "ISP-A", conforme demonstrado anteriormente.
Resultados Obtidos:
Na imagem abaixo, no Performance SLAs criado, podemos observar que o "ISP-A" já não possui comunicação com o 1.1.1.1, status contrário do "ISP-B":
No SD-WAN Rules, podemos observar que o SD-WAN selecionou o "ISP-B" como interface de saída do tráfego, conforme imagem abaixo:
E por fim, realizamos um teste de captura de pacote, onde foi feita uma captura na eth0/1 do "ISP-WORLD" que é conectado no "ISP-B", para provar que o tráfego gerado está chegando via "ISP-B" no "ISP-WORLD". Segue vídeo abaixo:
O Fortigate selecionou o "ISP-B" para esta comunicação devido ao route-lookup proccess dar preferência às rotas do SD-WAN antes do que as rotas da FIB, conforme Figura 4 abaixo, retirado do Forum da Fortinet:
Resultado Final
Como resultado final, o cliente obteve um ambiente de rede tolerante a falhas, onde a sua rede pública está sendo anunciada para dois provedores diferentes via Protocolo BGP. Em caso de falha do provedor principal "ISP-A", o Fortigate do cliente seguirá recebendo a rota default via "ISP-B", assim como o anuncio da sua rede pública este provedor seguirá funcionando.
Também foi possível usufruir do SD-WAN para obter um melhor desempenho da rede de acordo com as regras aplicadas, independentemente de qual provedor está como primário via tabela de roteamento FIB.
Comments