Redirecionar o tráfego de entrada para outro roteador que não esteja executando o BGP

Pessoas,

Eu tenho dois roteadores no núcleo do meu ISP. O primeiro deles é um pouco antigo equipamento Cisco, que é onde eu tenho sessões eBGP com meus upstreams, IX e downstreams. O segundo é um MikroTik CCR, que atua como servidor DHCP, firewall etc. para meus clientes.

Devido ao aumento de nossa rede, o roteador antigo da Cisco não está conseguindo lidar com todo o tráfego atual de maneira fluida, mas por motivos internos, não podemos alterá-lo para outro equipamento no momento.

Estou pensando em redirecionar todo o tráfego de entrada diretamente para o equipamento MikroTik, de tal maneira que ele não precise ser roteado pelo Cisco. Mas não tenho certeza se é possível.

Eu uso um intervalo / 29 com cada um dos meus upstreams, para que o roteador MikroTik seja endereçado dentro do mesmo intervalo que o meu e os roteadores de borda do upstream. Ex.:

• 1º roteador da Upstream: 198.51.100.1/29
• Segundo roteador do Upstream: 198.51.100.2/29
• Meu roteador Cisco: 198.51.100.6/29
• Meu roteador MikroTik: 198.51.100.5/29

192.0.2.1 é o gateway padrão para o roteador MikroTik (192.0.2.2).

Seria fácil resolver isso usando o prefixo como caminho se o equipamento MikroTik estivesse executando o BGP, mas não é e não pode ser por razões técnicas e comerciais.

Eu pensei que o redirecionamento pudesse ser feito alterando o atributo BGP next-hop dos prefixos anunciados para o endereço IP do roteador MikroTik, da seguinte maneira (em conformidade com o diagrama de rede acima):

route-map CHANGE_NEXTHOP permit 10
 set ip next-hop 198.51.100.5
!
router bgp XXXXXX
 neighbor 198.51.100.1 route-map CHANGE_NEXTHOP out
 neighbor 198.51.100.2 route-map CHANGE_NEXTHOP out
!

Dessa forma, o tráfego de upload fluiria através da conexão direta entre os dois roteadores, enquanto o tráfego de download fluiria dos upstreams diretamente para o roteador MikroTik.

No entanto, li em algum lugar que isso só é possível quando as sessões BGP são multihop, não quando os vizinhos estão diretamente conectados. Além disso, pelo que entendi, alterar o próximo salto é um recurso exclusivo do iBGP.

Estou longe de ser um especialista da Cisco e procurei muito, mas não encontrei uma resposta conclusiva para minhas dúvidas, então alguém poderia me dizer se é possível fazer o que descrevi na configuração acima. snippet ou sugerir alguma solução para minha situação complicada?

Infelizmente, atualmente não tenho como executá-lo em um laboratório (mesmo usando máquinas virtuais) para testar se funciona como pretendido.

Serei grato por isso e por qualquer informação adicional que você fornecer.

Pode haver uma maneira de conseguir isso explorando a seguinte regra de próximo salto do BGP:

Do RFC 4271, 5.1.3 NEXT_HOP:

Ao enviar uma mensagem para um par externo, X e o par estão a um salto de IP do alto-falante:

- Se a rota anunciada foi aprendida de um par interno ou se originou localmente, o alto-falante BGP pode usar um endereço de interface do roteador interno (ou roteador interno) através do qual a rede anunciada pode ser alcançada pelo alto-falante para o atributo NEXT_HOP , desde que o par X compartilhe uma sub-rede comum com esse endereço. Esta é uma forma do atributo NEXT_HOP de "terceiros".

Você poderia tentar isso:

• Remova a adjacência OSPF entre Cisco e Mikrotik na rede 192.168.2.0/30

• Crie a adjacência OSPF entre os roteadores Cisco e Mikrotik na rede compartilhada 198.51.100.0/29

• Verifique se as rotas que o roteador Cisco está aprendendo via OSPF têm um salto seguinte de 198.51.100.5

• Limpe as sessões BGP. O roteador Cisco agora deve anunciar rotas para sub-redes internas com um BGP NEXT_HOP de 198.51.100.5

Este artigo mostra um exemplo:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html

Próximo salto BGP (redes multiacesso)

Este exemplo mostra como o próximo salto se comporta em uma rede multiacesso, como Ethernet.

Suponha que o RTC e o RTD no AS300 executem o OSPF. O RTC executa o BGP com o RTA. O RTC pode alcançar a rede 180.20.0.0 via 170.10.20.3. Quando o RTC envia uma atualização do BGP para o RTA em relação a 180.20.0.0, o RTC usa o próximo salto 170.10.20.3. O RTC não usa seu próprio endereço IP, 170.10.20.2. O RTC usa esse endereço porque a rede entre RTA, RTC e RTD é uma rede de multiacesso. O uso de RTD pelo RTA como um próximo salto para atingir 180.20.0.0 é mais sensível do que o salto extra via RTC. Nota: O RTC anuncia 180.20.0.0 para o RTA com um próximo salto 170.10.20.3. Se o meio comum para RTA, RTC e RTD não for multiacesso, mas NBMA, outras complicações ocorrerão.

Suponho que você queira afetar o tráfego da Internet INBOUND e saiba como lidar com o tráfego da OUTBOUND.

Em seguida, a maneira mais fácil de fazer isso seria fazer o " prefixo no caminho " no roteador Cisco quando estiver anunciando para o upstream. Então, seu tráfego de Internet INBOUND definitivamente seguiria o caminho mais curto em sua direção, que será através do roteador MikroTik.

Para ver um exemplo, veja isso .

Crie um endereço vrrp para o cisco e o mikrotik e torne esse o gateway padrão no switch principal. Defina o mikrotik como o membro de maior prioridade.

O mikrotik deve ter uma rota padrão recebida do roteador cisco e uma de "minha rede", preferindo "minha rede" como rota preferencial. Isso pode ser via OSPF ou atribuído estaticamente.

Tenha uma ponta de prova do IP SLA do microtik ou do Cisco para verificar a conectividade upstream a "minha rede". Se houver um problema a montante, reduza a prioridade do vrrp no roteador mikrotik para que o tráfego saia pelo cisco.

Na instalação, você terá redundundância e não terá problemas com o tráfego de entrada via cisco, assumindo que você está natando o tráfego de entrada no cisco. O tráfego de entrada e saída seguirá caminhos diferentes.

O MicroTik suporta BGP . Redirecionar o tráfego de entrada pode exigir que você execute o BGP.