[GTER] iBGP e eBGP Bakcbone

[Ricardo Tavares]

Boa noite,

Communities continuam sendo a melhor opção aliado ao uso de filtros de
AS-PATH e número máximo de prefixos.

Em relação as comunidades o ideal é usar uma lista de comunidades, por
exemplo:

Na entrada (route-map IN na sintaxe Cisco):

Uma sessão eBGP com um trânsito internacional recebe uma community ASN:X
Uma sessão eBGP com um peer nacional/internacional  recebe uma community
ASN:Y (similar a receber rotas de clientes mas podendo conter AS-PATHS
adicionais que devem ser permitidos via filter-list para não acontecer de
receber rotas vazadas)
Uma sessão eBGP com um cliente poderia receber uma community ASN:ASN (essa
sessão recebe as rotas dos ASN que são clientes do teu provedor de acesso)

Na saida (route-map OUT na sintaxe Cisco):

Rota eBGP internacional (ASN:X) é anunciada somente para clientes junto com
rotas de outros clientes (ASN:ASN), uma rota ASN:X nunca é anunciada para
outro trânsito/peer

Toda rota marcada com ASN:ASN é anunciada para os peers
nacionais/internacionais


Se você tiver muitas bordas internet e provavelmente estiver usando
refletores é possível definir políticas para saídas tipo hot-potato com
facilidade e usar cold-potato como contingência. Quer dizer, determinado
cliente sai pelo link externo mais próximo (hot-potato) e em caso de
necessidade por outros links. Isso é possível de se fazer observando
determinada community (por exemplo ASN:DD) e aplicando metricas
diferenciadas em cada refletor, assim o refletor de Curitba "vê" rotas com
origem na borda de Curitba melhor do que vê as mesmas rotas vindas das
bordas de Brasília, já o refletor de Brasília vê o inverso..como faz isso?
Aplicando policies nas rotas que recebe de seus irmãos no cluster de
refletores...

Exemplo:


Transito Internacional chegando em Brasilia, a community-list poderia ser
aplicar para cada rota duas comunidades: ASN:1 ASN:61

Transito Internacional chegando em Curitiba, a community-list poderia ser
aplicar para cada rota duas comunidades: ASN:1 ASN:41

Transito peering chegando em Brasilia, a community-list poderia ser aplicar
para cada rota duas comunidades: ASN:2 ASN:61

A maioria das operadoras usa uma estratégia similar...tem o pessoal do
MPLS-TE mas eu não sou muito fã de MPLS-TE para isso.

Finalmente, um bom plano de comunidades BGP é importante porque dependendo
das habilidades de REGEX do teu sistema operacional nos roteadores, bolar
uma sequencia de comunidades com certa lógica de "match" é muito
interessante.

Tem um provedor internacional que publica sua estratégia de marcação de
comunidades em seu site, não consigo lembra agora quem é...talvez a Level
3, se lembrar eu posto aqui...



Divirta-se, sei que falei muito e dei poucos exemplos, mas se você usar um
simulador poderá brincar com essas ideias e criar seus próprios mapas.


2016-03-01 15:33 GMT-03:00 Hernest Hammer <hernesthammer at gmail.com>:

> Boa tarde,
>
>  Qual a melhor forma de se controlar anúncios entre peers internos e
> externos em uma rede composta de camada de acesso e backbone?
>
>  Em uma topologia onde um roteador recebe anúncios eBGP de clientes e
> repassa para os roteadores de backbone, o controle é feito por communities?
> Filtros são aplicados apenas na camada de acesso ou também no backbone?
>
>  Imagino que os edges com operadoras (trânsito, ptt, trocas, etc) devem ter
> o mínimo de intervenção possível, então a idéia de communities me parece
> compatível.
>
>  É comum ter filtros (firewall) para não deixar sair pacotes que não se
> originem na própria rede? Ou apenas filtros de BOGONS? Isso também é feito
> na camada de acesso?
>
>  Obrigado pessoal.
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter