[GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509

Sun Aug 16 00:26:27 -03 2020

Bom, isso realmente pode ser uma das questões que eles querem resolver.

mas isso seria algo que o IX-BR deveria resolver. eu mesmo esses dias abri
uma thread sobre isso e descobri que falhas de arp no atm são bem comuns.

isso me fez ter que parar de preferir as rotas do IX SP. como somos uma
empresa "mostly inbound" não teria tanto impacto pra nós, mas se todos
fizerem como eu fiz acaba-se o propósito do PTT. falhas de arp são falhas
notórias que impedem o objetivo real do PTT.

O upload dos demais participantes são meu download. se todo mundo tiver que
preferir trânsito ao PTT, então acabou o PTT.

Faz sentido usar sessões bilaterais realmente, se o arp não responde a
sessão não fecha, não recebe as rotas.

Mas ainda assim, negócio é uma baita gambiarra pra resolver um problema que
afeta todo mundo e que deveria já ter uma prioridade de urgência para se
resolver. quem sabe seguir o caso do AMSIX do Arp sponge.

Em sáb, 15 de ago de 2020 17:52, Rodrigo Pedrosa de Aguiar <
rodrigopa.uepb at gmail.com> escreveu:

> Boa tarde, acredito que tenham várias razões, algumas relativas a um maior
> controle/gerencia, mas principalmente a alguns problemas que podem
> acontecer, como por exemplo, algum dos participantes tem problema de
> conectividade com outros participantes, muitas vezes relacionados a
> resolução/tabela arp, no caso ele envia as suas rotas para os router
> servers, e outros participantes aprendem essas rotas pelos router server,
> entretanto não conseguem encaminhar corretamente, pois ou não recebem a
> entrada ARP do Participante ou o Participante não recebe a sua, causando
> indisponibilidade, isso não aconteceria caso fosse recebido via sessão
> bilateral, pois para fechar a sessão os participantes teriam que ter
> conectividade entre si. Claro, que depois de percebido o problema, pode-se
> usar filtros para evitar aprender e enviar anúncios para determinado
> participante, problema é que isso tem um tempo de reação e caso o problema
> for intermitente, pode demorar mais ainda a identificação do problema.
> Eu mesmo estou com um chamado aberto com o IX.BR por causa disso, alguns
> participantes do IX.SP (identifiquei 4), eu não tinha conectividade, alguns
> nem recebia os MAC Address, o IX em contato com o participante informou que
> estava com problema e até hoje (5 a 6 meses depois) ainda não resolveu, o
> próprio IX informou que colocaria o participante na quarentena.
>
>
> Att.,
> Rodrigo Pedrosa.
>
> Em sáb., 15 de ago. de 2020 às 15:46, Fernando Frediani <
> fhfrediani at gmail.com> escreveu:
>
> > +1
> >
> > On Sat, 15 Aug 2020, 13:09 Andre Almeida, <andre at bnet.com.br> wrote:
> >
> > > pra mim a única explicação é que eles não confiam nos route servers.
> > >
> > > hoje em dia tendo as communities de engenharia de tráfego e marcação de
> > > rotas,
> > > não tem sentido nenhum sair do route server pra servir tráfego via
> mesma
> > > vlan do ATM só que fazendo o roteamento através de sessões individuais
> > com
> > > cada participante.
> > >
> > > E pra cada participante que entra no atm depende de intervenção para
> > criar
> > > mais uma sessão (ou nesse caso várias). sinceramente, quase nada
> > escalável.
> > > queria mesmo entender os argumentos da mente brilhante que tomou essa
> > > decisão.
> > >
> > > o route server tá ali justamente pra que todo mundo não precise
> realizar
> > > essas sessões bilaterais.
> > >
> > > pra mim não faz sentido algum, a não ser que eles achem que os route
> > > servers não fazem bem o papel deles e que vale a pena eliminar eles pra
> > ter
> > > mais estabilidade.
> > >
> > >
> > > Em sáb, 15 de ago de 2020 12:06, Alexandre C. Fonceca <
> > > alexandre at specialist.srv.br> escreveu:
> > >
> > > > mas com a sessao rodando na mesma vlan do IX normal, nao teria meios
> de
> > > > diferenciar o trafego em relação às mesmas rotas deles aprendidas via
> > > > routers servers..
> > > >
> > > > e qualquer forma de medir via AS (analisando netflows?!) daria tb
> para
> > > > fazer igualmente via routers servers..
> > > >
> > > > logo....
> > > >
> > > >
> > > > On 15/08/2020 12:03, Bruno Cabral wrote:
> > > > > Medirem consumo?
> > > > >
> > > > > --
> > > > > Cursos e Consultoria BGP e OSPF
> > > > > ________________________________
> > > > > De: gter <gter-bounces at eng.registro.br> em nome de Alexandre C.
> > > Fonceca
> > > > <alexandre at specialist.srv.br>
> > > > > Enviado: sexta-feira, 14 de agosto de 2020 23:55
> > > > > Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> > > > gter at eng.registro.br>
> > > > > Assunto: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
> > > > >
> > > > > por curiosidade, alguem sabe me dizer pq algumas empresas preferem
> > > fazer
> > > > > sessão direta com os participantes do que usar os routers servers
> do
> > > > > próprio IX?
> > > > >
> > > > > tecnicamente falando, se os prefixos sao os mesmos (anunciados para
> > os
> > > > > routers servers do IX e para o participante direto), nao mudaria
> nada
> > > no
> > > > > trafego... porem CONSUMIRIA mais recursos no próprio router deles
> > mesmo
> > > > > (se todos pedissem a sessao bilateral)...
> > > > >
> > > > > qual vantagem nisso? que nao daria para ter/fazer via ix direto...
> > > > >
> > > > >
> > > > >
> > > > > -------- Forwarded Message --------
> > > > > Subject:         [IX.br] [Info] Peering Amazon / AWS - AS16509
> > > > > Date:    Fri, 14 Aug 2020 20:09:49 +0000 (UTC)
> > > > > From:    IX.br <no-reply at meu.ix.br>
> > > > > Reply-To:        eng at ix.br
> > > > > To:      alexandre at specialist.srv.br
> > > > >
> > > > >
> > > > >
> > > > > * English version below
> > > > >
> > > > > Bom dia
> > > > >
> > > > > Este é um email gerado automaticamente pela equipe de peering da
> > > Amazon.
> > > > >
> > > > > Este email tem como objetivo notificar aos membros do PTTMetro de
> São
> > > > > Paulo que Amazon ASN 16509 deixará o Route Server em 31 de agosto
> de
> > > > 2020.
> > > > >
> > > > > Com base na informação de https://www.peeringdb.com/, configuramos
> > uma
> > > > > sessão do BGP com você, que está pronta para ser colocada em
> serviço.
> > > Se
> > > > > você ainda tem presença no
> > > > > Exchange e gostaria de concluir as sessões de peering connosco
> > > > > (AS16509), você poderia configurar seu lado de acordo com a
> > informação
> > > > > de peering abaixo citada.
> > > > >
> > > > > Amazon ASN: 16509
> > > > > Amazon IPv4 address: 187.16.216.95
> > > > > Amazon IPv6 address: 2001:12f8::95
> > > > > Amazon IPv4 address: 187.16.217.163
> > > > > Amazon IPv6 address: 2001:12f8::217:163
> > > > > Amazon IPv4 address: 187.16.221.99
> > > > > Amazon IPv6 address: 2001:12f8::221:99
> > > > > Amazon IPv4 address: 187.16.221.239
> > > > > Amazon IPv46 address: 2001:12f8::221:239
> > > > >
> > > > > Por favor, certifique-se de que sua informação este atualizada em
> > > > > peeringdb.com para todo o seu IP (v4 e v6). Também extraímos o
> > limite
> > > > > máximo de prefixos, a entrada de IRR e os e-mails de contato do
> > > > > peeringdb.com, certifique-se de que eles sejam precisos.
> > > > >
> > > > > Uma vez que as sessões são estabelecidas, ele permanecerá no estado
> > > > > filtrado até que seja filtrado dentro de dez dias úteis.
> > > > >
> > > > > Qualquer dúvida consulte peering at amazon.com
> > > > >
> > > > > Obrigado pelo peering
> > > > >
> > > > > Equipes de Engenharia de Peering e Capacitação da AMAZON
> > > > > peering at amazon.com
> > > > >
> > >
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > > > [ English ]
> > > > > Good Day
> > > > >
> > > > > This is an email from Amazon's Peering team.
> > > > >
> > > > > The purpose of this email is to notify all PTTMetro Sao Paulo
> members
> > > > > that Amazon ASN 16509 is going to leave the Route Server on August
> 31
> > > > 2020.
> > > > >
> > > > > Based on current https://www.peeringdb.com/ information we have
> > > > > configured a BGP session with you which is ready to be put in
> > service.
> > > > > If you still have presence in the Exchange and would like to
> complete
> > > > > the peering sessions with us (AS16509), could you please configure
> > your
> > > > > end according to below peering information.
> > > > > Amazon ASN: 16509
> > > > > Amazon IPv4 address: 187.16.216.95
> > > > > Amazon IPv6 address: 2001:12f8::95
> > > > > Amazon IPv4 address: 187.16.217.163
> > > > > Amazon IPv6 address: 2001:12f8::217:163
> > > > > Amazon IPv4 address: 187.16.221.99
> > > > > Amazon IPv6 address: 2001:12f8::221:99
> > > > > Amazon IPv4 address: 187.16.221.239
> > > > > Amazon IPv46 address: 2001:12f8::221:239
> > > > >
> > > > > Please make sure that your information is up-to-date on
> > peeringdb.com
> > > > > for all your IP (v4 and v6). We also pull max-prefix limit, IRR
> entry
> > > > > and contact e-mails from peeringdb.com, please ensure that they
> are
> > > > > accurate.
> > > > >
> > > > > Once the sessions are established, it will stay in filtered state
> > until
> > > > > it is unfiltered within ten working days.
> > > > >
> > > > > Any questions refer to peering at amazon.com
> > > > >
> > > > > Thanks for peering
> > > > > AMAZON Peering and Capacity Engineering teams
> > > > > peering at amazon.com
> > > > >
> > > > > --
> > > > > Galvao Rezende
> > > > > Brasil Internet Exchange (IX.br)
> > > > > Núcleo de Informação e Coordenação do Ponto BR (NIC.br)
> > > > > --
> > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > > --
> > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>