[GTER] Ajuste de Localpref, MED e Participação em IX Regionais

Douglas Fischer fischerdouglas at gmail.com
Mon Aug 24 08:56:42 -03 2020


P.S. 0: Hoje tem histórinha para os amiginhos que me procuraram no
particular para dizer que estavam com saudades.


Olá Josivan!
A metodologia que você mencionou adotar (Local-Pref Mais pesados para IXP
mais próxmos) é realmente a mais comum.
Mas não é a metodologia ideal!

E justamente por saber que você não é do tipo que vai se doer e nem ficar
de mi-mi-mi.
Vou pegar o seu exemplo, vou aprofundá-lo com mais elementos, e vou
detalhar aonde o problema acontece.
Espero que não fique incomodado... Pois o foco é técnico e melhorar a
Internet como um todo.

Você disse:
"Sempre configuro o local preference das conexões ao IX.br assim:
IX-LOCAL (Onde vc tá com infra própria até o PIX) > IX-REGIONAL > IX-SP OU
RJ"


Digamos que A JosivanNET seja um provedor no em torno de Brasília,
atendendo Guará, Taguatinga...

P.S. 1: As cidades escolhidas neste exemplo foram para tornar evidente o
problema que quero demostrar.
Os nomes escolhidos nessa "E"stória não tem inspiração nenhuma em qualquer
empresa real(a não ser a JosivanNET, hehe).
P.S. 2: Nesse primeiro momento só vou falar das rotas na FIB do próprio ASN.
Vamos deixar o ponto de vista de como o AS influencia a recepção de pacotes
para outro momento.

Com todos os ISPs quando crescem um pouco, a JosivanNET além dos trânsitos
IP descolou um transporte até o IX.BR-SP(na época que chamava PTT ainda).
E também, para conseguir oferece uma comunicação de qualidade entre seu
clientes e a SERPRO, ele se ligou ao IX.BR-DF.

Com isso a JosivanNet resolveu seguir a receita de bolo padrão,
 - Rotas recebidas dos Trânsitos com LocalPref de 100
 - Rotas recebidas dos route-servers do IX-BR.SP com LocalPref de 200
 - Rotas recebidas dos route-servers do IX-BR.DF com LocalPref de 300
OPA! Até aqui perfeito certo?
 - Rotas da Serpro sendo mais preferidas pelo IX.BR-Regional.
 - Facebook e Google pelo IX.BR-SP sendo mais preferidas que os trânsitos.
Tudo lindo né?


Mas aí apareceu na jogada duas outras empresas:
- A CoisasDivertidasCloud, que é uma empresa de hosting, que hospeda
conteúdo, e que está com seus servidores no RJ.
- A OutraNET, que é uma empresa de trânsito Internet com operação em
Fortaleza.

A CoisasDivertidasCloud tem hospedado em seu hosting um conteúdo que teve
bastante adesão pelos gringos da parte norte do Globo Terrestre...
Então se preocupou em contratar uma empresa com um custo baixo para levar
esse conteúdo para a gringolândia com uma baixa latência, e um custo baixo.
Foi então que a OutraNET foi contratada.
Além levar isso para um monte de lugares das gringas, ela teria que
entregar isso também em pelo menos 12 dos IX.BR-Regionais, incluíndo o
IX.BR-DF.


Vamos esquecer um pouquinho a gringolândia nesse nosso exemplo, e focar no
Brasil. Apenas para fazer entender a quetão...

Bom, as rotas da  CoisasDivertidasCloud começaram a aparecer nos
IX.BR-Regionais atrás do AS da OutraNET.
(Ficou claro até aqui?)

A OutraNET tinha roteadores em Fortaleza, Rio de Janeiro e São Paulo. E uma
rede de transporte entre esses POPs.

Dessa forma, as rotas da CoisasDivertidasCloud eram aprendidas no Border do
RJ da OutraNET, e enviadas por iBGP para SP e Fortaleza.
Com isso a OutraNET anunciava as redes da CoisasDivertidasCloud da seguinte
maneira:
 - IX.BR-RJ -> Pelo mesmo Border que falava com a CoisasDivertidasCloud,
entregava com 1ms de latênca.
 - IX-Equinix-RJ -> Pelo mesmo Border que falava com
a CoisasDivertidasCloud, entregava com 1ms de latênca.
 - IX.BR-SP -> Pelo Border que Tinha em SP, e recebia as rotas por iBGP do
Border de RJ, entregava com 5ms de latênca.
 - IX-Equinix-SP -> Pelo mesmo Border que falava com
a CoisasDivertidasCloud, entregava com 5ms de latênca.
 - IX.BR-SP -> Pelo Border que Tinha em SP, e recebia as rotas por iBGP do
Border de RJ, entregava com 5ms de latênca.
 - IX-Equinix-SP -> Pelo mesmo Border que falava com
a CoisasDivertidasCloud, entregava com 5ms de latênca.
 - IX.BR-CE -> Pelo Border que Tinha em Fortaleza, e recebia as rotas por
iBGP do Border de RJ, entregava com 24ms de latênca.
Mas lembram que eu falei que a OutraNET tinha sede em Fortaleza?
Então o Centro de roteamento mais forte é de lá, as redes construídas, os
contratos de transporte, foram construídos ao longo dos anos partindo de lá.
E com isso, presença da OutraNET no IX.BR-DF era a partir do Router de
Fortaleza. E aí as rotas da CoisasDivertidasNET ficava assim:
 - IX.BR-DF -> Pelo Border que Tinha em Fortaleza, e recebia as rotas por
iBGP do Border de RJ, entregava com 57ms de latênca.


Agora vamos voltar para ver como isso ficava na RIB e na FIB da JosivanNET.
 - Rotas recebidas dos Trânsitos com LocalPref de 100
 - Rotas recebidas dos route-servers do IX-BR.SP com LocalPref de 200
 - Rotas recebidas dos route-servers do IX-BR.DF com LocalPref de 300

Nesse caso, a JosivanNET iria:
Preferir a rota que ela recebe no IX.BR-DF, com 57 ms de latência(mais 1ms)
até seu pop.
 - Josivan-NET -> IX.BR-DF -> OutraNET em Recife -> Rio de Janeiro ->
CoisasDivertidasCLOUD
Deixar de preferir a rota que ela teria pelo IX.BR-SP, com 16ms de latência
até seu pop.
 - Josivan-NET -> IX.BR-BR -> OutraNET São Paulo -> Rio de Janeiro ->
CoisasDivertidasCLOUD

E tudo isso porque?
Porque a JosivanNET usou critérios de escolha do BGP mais pesado(em
situações comuns).
Tiro de canhão para matar mosquito.


Já vou atencipar aqui os mi-mi-mis:
"Ainnn... Mas a CoisasDivertidasCLOUD escolheu uma empresa ruim para fazer
a entrega de suas rotas."
-> O que VOCÊ, oque O SEU ASN, pode fazer com relação as escolhas técnicas
e comerciais de outros ASNs?
"Ainnn... Mas a OutraNET deveria ter um transporte entre SP e RJ."
-> E VOCÊ vai obrigar eles a fazer isso como? Quem tem que exigir ou deixar
de exigir coisas assim é a contratante! A CoisasDivertidasCLOUD.
   E ela sabe que exigir coias assim vai afetar no preço que ela vai
pagar... Lembrando que o foco deles era a parte norte do Globo Terrestre.



"Tá Douglas, seu chatão! E o que a gente pode fazer para resolver isso?"

PAREM DE USAR LOCAL-PREF COMO SE FOSSE UM CRITÉRIO LEVE!
NÃO É LEVE, É PESADO! Mais pesado que AS-PATH, Mais pesado que MED.

Costumo dizer que Loca-pref é como um Antibiótico, e o MED é um
antinflamatório.
Se vocÊ usar Antibiótico sempre que tiver qualquer prenúncio de doença, seu
sistema imunilógico vai ficar debilitado.


Não vou detalhar muito sobre o MED baseado em latência aqui por que esse
e-mail já ficou muito longo, e para não dar spoiler da apresentação que
farei no LACNOG.
Mas não precisa de tanto esforço assim para imaginar onde o MED baeado em
latência, aditivo a cada salto, resultaria.


Abraços!


Em sex., 21 de ago. de 2020 às 13:25, Josivan Barbosa <
josivan.barbosa01 at gmail.com> escreveu:

> Sempre configuro o local preference das conexões ao IX.br assim:
>
> IX-LOCAL (Onde vc tá com infra própria até o PIX) > IX-REGIONAL > IX-SP OU
> RJ
>
> E o MED seguindo a mesma lógica de acordo com a característica do atributo:
>
> IX-LOCAL (Onde vc tá com infra própria até o PIX) < IX-REGIONAL < IX-SP OU
> RJ.
>
> Se tem mais de um IX em cada "categoria", uso como "desempate" latência e
> banda disponível.
>
>
> Em sex., 21 de ago. de 2020 às 06:05, Tales Rodarte <
> talesrodarte at gmail.com>
> escreveu:
>
> > Para quem é do Norte/Nordeste pode usar como referencia o DDD:
> >
> > Região de Teresina:
> >
> > Priorização de upload baseado no as-path - 799
> > IX-THE  -   786
> > IX-CE   - 785
> > IX-NAT - 784
> > IX-RIO -  721
> > IX-SPO - 711
> >
> > Agora se for do sul  vai precisar de mais um numeral. hehe
> > Já para AS que possuem vários IXs e deseja priorizar o download, muitas
> > vezes acaba usando prepend (que pode acabar efeitos inesperados
> > dependendo da politica de anúncios), é mt estratégico usar MED como
> > destacado.
> >
> > As vezes com estes pequenos ajustes você melhora a experiência de uso
> > daquele cliente que precisa acessar conteúdos de um AS próximo a você e
> > que participa do mesmo IX regional.
> >
> > --
> >
> > Tales Rodarte
> >
> > Em 21/08/2020 00:57, Fernando Frediani escreveu:
> > > Olá pessoal.
> > >
> > > Esta mensagem é principalmente direcionada à todos aqueles Sistemas
> > > Autônomos que além de participarem de IX de grande porte como SP, RJ,
> > > CE, RS, etc também estão conectados à algum IX Regional em sua cidade
> > > ou região no interior dos Estados.
> > >
> > > Aqui em nossa operação além de estarmos conectados ao IX-SP também
> > > estamos à um IX Regional do Estado e verificando o gráfico de troca de
> > > tráfego percebi que o tráfego de entrada é menor do que o de saída, o
> > > que não é algo esperado para um provedor de acesso e banda larga.
> > > Conversando com uma pessoa que possui o mesmo cenário ele também
> > > relatou o mesmo.
> > > E outra característica interessante é que quando acontece alguma
> > > intermitência no IX-SP (ou o IX maior) ou no transporte que conecta
> > > ai, passa a entrar mais tráfego através do IX Regional em questão. Ou
> > > seja, havia tráfego que poderia entrar naturalmente por ali mas está
> > > dando a volta em São Paulo.
> > >
> > > Isso pode indicar que outros participantes que também participam de
> > > ambos os IX podem ter configurado um Localpref maior para o IX-SP do
> > > que para o IX Regional. Talvez porque o IX-SP foi ativado antes e
> > > quando se ativou o IX Regional pode-se ter esquecido de igualar.
> > > Na verdade o ideal é deixar os Localprefs iguais e deixar com os
> > > outros participantes que também abordam os múltiplos IX como neste
> > > exemplo que indiquem através do atributo MED por onde preferem receber
> > > o tráfego e que será o critério de desempate do BGP. Ainda sim, (mesmo
> > > não recomendando dessa forma) caso houver uma razão muito específica
> > > prefiram ter o Localpref maior para o IX Regional do que para o IX-SP
> > > (RJ, CE, RS, etc).
> > >
> > > Geralmente o custo do Megabit para os IX Regionais daqueles que já
> > > participam tende a ser sempre menor o que será sempre uma economia
> > > para o provedor, mais importante ainda reduza latência que deixa de
> > > ter que dar a volta até São Paulo e passa trocar tráfego ali na
> > > própria região, liberando assim parte do transporte para São Paulo
> > > para o tráfego que realmente precisa vir dali.
> > >
> > > Minha sugestão é que aqueles que possuírem cenários semelhantes
> > > revisem seus Localprefs e se for o caso passem a utilizar também MED.
> > > Caso alguém tiver alguma outro sugestão complementar ou experiência
> > > diferente é bem vinda e será interessante saber.
> > >
> > > Obrigado
> > > Fernando Frediani
> > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
> --
> Att
>
> Josivan Barbosa
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação


More information about the gter mailing list