É possível influenciar remotamente o BGP localpref?

17

Um colega está tentando implementar o compartilhamento múltiplo ativo / passivo da Internet. O design implica o envio de comunidades (listadas abaixo) ao provedor passivo para diminuir a preferência local em ASes remotos para as rotas anunciadas. A documentação declara repetidamente que as comunidades são para uso do cliente e não somos clientes desses fornecedores. Eu acho que dar à Internet em geral a capacidade de alterar a preferência local é um enorme risco de segurança. Isso teria uma chance de bola de neve no inferno de realmente funcionar?

1273:70     cable and wireless plc local pref 70
2828:1507   xo local pref 70
3356:70     level3 local pref 70
3549:100    global crossing local pref 100
4323:80     twtelecom local pref 80
1299:50     teliasonera local pref 50

bgp

— Dennis Olvany
fonte

1

O 'onestep' é seu próprio provedor de backup? Nesse caso, certifique-se de que eles funcionem bem quando anunciados para 'ultrapassar' e, na minha opinião, é um design preferível ao invés do prefpend. Caso contrário, eles serão inúteis, mesmo que suas rotas os passem, é improvável que eles trabalhem com seus pares. O seu vizinho direto não fornece lista comparável?

— ytti

One Step não é nosso provedor. Pelo que entendi, o One Step não é um provedor. O vizinho direto pode ter essa lista. Vou ter que fazer alguma pesquisa.

— Dennis Olvany

2

O OneStep é uma consultoria que agrega guias da comunidade de todos os NSPs.

— generalnetworkerror

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

15

É improvável (mas não impossível) que as comunidades que você rotula nas suas rotas se propagem além do seu upstream. A maioria dos provedores retirará as comunidades antes de ler as rotas de publicidade para cima / para baixo.

Se você quiser influenciar vários ASes remotos dessa maneira, precisará usar o prefixo AS_PATH. Anexe de 2 a 3 vezes ao seu provedor de backup / passivo e, em seguida, a maioria / todo o tráfego fluirá pelo seu caminho ativo até que falhe. O tráfego deve passar para o seu caminho passivo assim que a rota com falha for retirada.

— Justin Seabrook-Rocha
fonte

4

Se o cliente A tiver trânsito do provedor P1 e P2 e ele for anexado ao P2. Em seguida, outro cliente B de P2 pode rotas locais_pref recebidas de P2 (talvez seja mais barato), ou seja, o prefixo não garante que todo o tráfego mude e não há maneira real de garantir isso no BGP, além de retirar a rota de rotas não preferenciais ou não preferenciais. vazando mais detalhes para o parceiro preferido, nenhum dos quais pode ser recomendado.

— ytti

2

Corrigir! Assim, a eterna luta da engenharia de tráfego, como influenciar uma rede com a qual você não tem relacionamento. Provavelmente eu deveria ter dito "a maioria" em vez de "tudo", mas os prependentes e mais específicos são realmente as únicas duas opções que podem realmente ter um efeito nesse caso.

— Justin Seabrook-Rocha

3

Como ytti disse, os truques do AS_PATH são, na melhor das hipóteses, uma sugestão. No final do dia, as preferências do administrador local vencerão. Se eu quiser que o tráfego de uma rede específica atravesse um link específico, será ; não há nada que a internet possa fazer para alterar minha configuração de roteamento.

— Ricky feixe

6

O provedor deve ter um filtro de entrada para garantir que essas comunidades sejam aceitas apenas pelos clientes. Caso contrário, esse é o problema dos provedores.

Alguns fornecedores de Nível 1 aceitam esse tipo de comunidade de qualquer lugar. Isso é baseado na RFC 1998: http://tools.ietf.org/html/rfc1998.html

— maduro
fonte

O consenso parece claro. Parece influenciar a preferência local de ASes remotos quase impossível.

— Dennis Olvany

5

O melhor que você geralmente pode fazer é procurar comunidades com seu provedor que permitam indicar prepends por ponto do seu provedor. Isso pressupõe que seu provedor tenha essas comunidades e tenha relações de pares para que isso funcione. Anexar seus próprios anúncios ao seu colega não teria variação a montante do seu provedor. Embora esse método não altere o localpref um AS removido do seu provedor, ele tem um impacto semelhante ao tornar esse caminho de volta para você menos desejável. Há uma exceção para influenciar o localpref upstream que descreverei na parte inferior, embora seja provavelmente um caso de ponta.

Alguns provedores , como o XO [AS2828], permitem que você anuncie seus prefixos de forma que seu provedor anuncie suas rotas com prefixos específicos para determinados pares deles.

Por exemplo, o XO aceita:

2828:1108precede uma vez para a AT&T
2828:1207precede duas vezes para o Nível 3
2828:1303precede três vezes para a Sprint

No Savvis, a comunidade é o 3561:30151prefixo uma vez para a AT&T.

Esses provedores geralmente têm comunidades para indicar as comunidades conhecidas de NO_EXPORT ou NO_ADVERTISE para pares específicos.

Um provedor de Nível 2 que eu conheço, o InterNAP, é capaz de influenciar os preços locais a montante, porque eles compram trânsito, por isso são clientes dos níveis 1. Eles têm comunidades que você pode usar, onde eles tentam convertê - los em comunidades específicas da camada 1 para seus anúncios upstream, que definem o localpref para valores de nível par , médio ou alto. Consulte http://www.onesc.net/communities/as6993/Internap-Customer-Guide-1.3.pdf .

Referências de exemplo:
comunidades XO que alteram anúncios de clientes para determinados pares no AS2828 Border Savvis Prefixam
atributos da comunidade

Não tenho nenhuma afiliação com os provedores usados nos exemplos além da experiência direta como cliente.

— generalnetworkerror
fonte