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


7

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

Diagrama de rede - núcleo

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.


Talvez eu esteja entendendo mal o que você está tentando realizar, mas como a configuração do que você descreve o ajuda a não precisar fazer eBGP nesse roteador Cisco? Um diagrama de rede pode ajudar muito aqui, mas o que você está fazendo aqui não funcionará como pretende. Além disso, o que é 192.51.100.5?
Teun Vink

Todos eles estão conectados ao mesmo segmento e você executa algum protocolo de roteamento interno entre o roteador Cisco e o dispositivo MikroTik? Também seria útil saber se este é um segmento Ethernet ou outra coisa. O comportamento padrão para ethernet parece não alterar o endereço do próximo salto anunciado quando anunciado no mesmo segmento que o endereço do próximo salto. Eu tentei isso em um pequeno laboratório com 4 roteadores conectados por um switch e no roteador Cisco, usei uma rota estática apontando para o MikroTik como próximo salto para redes conectadas a ele e as rotas anunciadas obtiveram o MikroTik como próximo salto automaticamente.
Jimmy

@TeunVink Preciso manter o eBGP no roteador Cisco, mas ele não pode mais lidar com todo o tráfego de rede atual. Não há 192.51.100.5 ... mas 198.51.100.5 é o meu roteador MikroTik, conforme descrito.
Tiago.SR

O roteador @ Jimmy Jim está diretamente conectado aos meus circuitos dedicados com upstreams. O roteador MikroTik pode ser adicionado ao mesmo segmento Ethernet por VLAN e ponte, tornando-se 198.51.100.5. É Ethernet. Estou tentando alterar esse comportamento padrão, definindo manualmente o próximo salto para o endereço IP do roteador MikroTik usando set ip next-hop...na Cisco. Vou desenhar um diagrama de rede e atualizar a postagem original o mais rápido possível.
Tiago.SR

11
A modificação do próximo salto do AFAIK pode ser usada para balancear o tráfego da maneira descrita. Geralmente ele deve funcionar, pelo menos do ponto de vista do Mikrotik, mas depende da configuração do roteador upstream. Por exemplo, filtros a montante podem proibir tais anúncios.
MMV-ru

Respostas:


1

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)

insira a descrição da imagem aqui

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.


0

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 .


Obrigado, você quase entendeu, exceto que o equipamento MikroTik não está executando o BGP e não é possível alterar isso. É principalmente por causa desses detalhes que falhei em obter uma solução para esse problema.
Tiago.SR 24/08/15

embora o prefixo AS-PATH seja comumente citado como uma solução para direcionar o tráfego para um roteador BGP específico, ele não é muito eficiente, muitos upstream se recusam a propagar prefixos com mais de três ocorrências do número AS e algum tráfego ainda virá " roteador de backup ".
JFL

@JFL isso não é verdade - o AS Path pré-pendente é uma maneira perfeitamente válida de cancelar a preferência do tráfego de entrada. O único tráfego que ele não afetará é que, do AS conectado diretamente ao upstream e de seus clientes - eles mais frequentemente ainda não usam a preferência local internamente para enviar tráfego para você pelo link, em vez de outro AS
Benjamin Dale

0

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.


Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.