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

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

— 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