Como lidar com a degradação do desempenho na rede do seu provedor?

9

Quais são algumas das maneiras possíveis de detectar a perda de pacotes na rede de um provedor que está a vários saltos de distância? Com vários provedores examinando o BGP em nossos roteadores de borda da Internet, preciso detectar automaticamente a perda de pacotes (principalmente) e a latência (secundariamente), fazer uma interface de rastreamento ou algo semelhante e desligá-los para que todo o tráfego use nossos outros provedores. .

Eu vi dois problemas com o uso de SLAs IP. Primeiro, o que precisa ser medido está a pelo menos vários saltos de distância (muito além do ponto BGP), portanto, monitorar qualquer coisa profunda na rede do provedor não é uma proposta estática, como monitorar nossos links com eles (que foram estáveis); se os links desse provedor forem encerrados, os SLAs ainda terão acessibilidade no caminho de outro provedor. Segundo, fazer um monitor do tipo ICMP não detecta o nível de perda de pacotes que geralmente é visto com pacotes muito maiores e a latência parece não mudar significativamente.

O Performance Routing (PfR) é a melhor opção aqui e influencia o localpref do BGP? Parece que o controlador mestre é um SPoF (ponto único de falha); portanto, se PfR é o caminho a seguir, como os roteadores de borda não podem depender de um único controlador mestre? Quais são duas ou três outras opções viáveis?

A maioria e o mais crítico de nosso tráfego são de nossas respostas HTTP de saída.

cisco bgp performance generalnetworkerror
fonte
Alguma resposta o ajudou? Nesse caso, você deve aceitar a resposta para que a pergunta não apareça para sempre, procurando uma resposta. Como alternativa, você pode fornecer e aceitar sua própria resposta.
Ron Maupin

Respostas:

6

PfR é de fato uma opção.

Opção em que eu pessoalmente não tenho experiência, mas sei que as pessoas que os utilizam são otimizadores de BGP, independentes do fornecedor, pois apenas olham para o BGP, medem a rede e injetam rotas para alterar o roteamento.

Opções de casal

  1. http://www.noction.com/intelligent_routing_platform
  2. http://www.internap.com/business-internet-connectivity-services/route-optimization-flow-control/
ytti
fonte
Obrigado pela opção e lembrete do InterNAP FCP. O INAP espiou esses roteadores, portanto, já temos um relacionamento com eles.
generalnetworkerror
7

Se você usar a Cisco no limite, o PfR seria realmente a melhor opção aqui pelos motivos que você especificou. Você pode configurar a redundância do controlador principal e a Cisco mostra como neste link: http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/Transport_diversity/PfR_Master_Controller_Redundancy.html

maduro
fonte
Basta ler o link: Você não pode ter um controlador em espera em outro local ou a única topologia com HSRP entre os controladores? E isso parece contrário ao que o PfR está tentando realizar se o caminho da fronteira para o controlador estiver degradado: "No caso de o roteador de borda PfR perder contato com o controlador mestre, o roteador de borda para de gerenciar prefixos ou aplicativos. Em outras palavras, o modo à prova de falhas de PdR é remover quaisquer rotas injetados na tabela de IP tabela de roteamento ou BGP e à política de parada roteamento de aplicações se o controlador mestre não está disponível ".
generalnetworkerror
Parece que o HSRP é o único caminho. É um pouco tolo em meus livros, pois a Cisco deve ser capaz de projetar o PfR para suportar dois controladores principais em duas sub-redes separadas. Você pode obter um VLL / VPLS para outro local e executar o HSRP sobre isso. Não é ideal, mas funciona. Qualquer 'L2 esticado' funcionaria aqui. Novamente, não é o ideal, mas funcionaria até a Cisco agir em conjunto e permitir dois controladores separados.
MellowD