From antonio.torres at vsat.com.br  Sat Aug  1 12:29:39 2020
From: antonio.torres at vsat.com.br (Antonio Torres)
Date: Sat, 1 Aug 2020 12:29:39 -0300
Subject: [GTER] geolocation Globoplay
In-Reply-To: <mailman.0.1596294001.26177.gter@eng.registro.br>
References: <mailman.0.1596294001.26177.gter@eng.registro.br>
Message-ID: <65BB5D2B-3554-4675-8FED-B7FDC65E7261@vsat.com.br>



> On 1 Aug 2020, at 12:00, gter-request at eng.registro.br wrote:
> 
> From: Epafras R Schaden <epafras.schaden at gmail.com <mailto:epafras.schaden at gmail.com>>
> Subject: [GTER] geolocation Globoplay
> Date: 31 July 2020 11:13:03 GMT-3
> To: <gter at eng.registro.br <mailto:gter at eng.registro.br>>
> 
> 
> Bom dia a todos.
> 
> 
> 
> Alguem saberia me informar qual a base de geolocaliza??o o servi?o da Globoplay usa para determinar as regi?es/cidades em que o servi?o ? suportado ou n?o ?
> 
> 
> 
> Abs,
> 
> 
> 
> Epafras
> 
> 
> 


At? a vers?o da semana passada (houveram atualiza??es mais recentes que ainda n?o fiz):

Nos ?mobiles? (Androide e iOS) os aplicativos Globo (todos) usam a localiza??o nativa do pr?prio device.
- Se voce bloquear a permiss?o de localiza??o n?o toca canal nenhum; 
- Se usar ?fake location? (no Android tem v?rios programas que permitem isso)  mudam os canais que podem ser assistidos;
- usando VPN n?o altera os canais que podem ser tocados.


Em dispositivos ?fixos? (PCs, SmartTVs, AndroidTV, etc.) eles usam uma base de GeoIP (que infelizmente n?o sei qual ?) + acordo com operadoras (Vivo, NET, etc. alimentam essa base)



[]s

Antonio Torres





From marcos.silva at telium.com.br  Tue Aug  4 09:26:22 2020
From: marcos.silva at telium.com.br (Marcos Silva)
Date: Tue, 4 Aug 2020 09:26:22 -0300
Subject: [GTER] =?utf-8?q?Tr=C3=A2nsito_AS?=
Message-ID: <f1479c3e-acdd-c85d-7f10-20294f6e6582@telium.com.br>

Bom dia pessoal,

Trabalho numa empresa que fornece tr?nsito IP para clientes, me deparei 
com uma situa??o curiosa onde o cliente n?o consegue comunica??o com 
destinos especificos com origem de seu AS, destinos como empresas para 
fechar uma comunica??o VPN, a partir do AS dele ele n?o consegue uma 
simples comunica??o ICMP com o destino que se encontra aberto para 
receber os pacotes. J? se depararam com casos como este? O cliente se 
encontra nos primeiros passos do AS. Realizamos o propaga??o para nossas 
operadoras de transporte corretamente sem realizar nenhum bloqueio, e 
mesmo por outro transito o cliente tem o mesmo comportamento anormal.


Atenciosamente,


Marcos Silva



From alexandre at opticalhost.com.br  Tue Aug  4 11:48:26 2020
From: alexandre at opticalhost.com.br (Alexandre Aleixo | Opticalhost)
Date: Tue, 4 Aug 2020 11:48:26 -0300
Subject: [GTER] =?utf-8?q?Tr=C3=A2nsito_AS?=
In-Reply-To: <f1479c3e-acdd-c85d-7f10-20294f6e6582@telium.com.br>
References: <f1479c3e-acdd-c85d-7f10-20294f6e6582@telium.com.br>
Message-ID: <CAO4k365c-PhNApn_1o3njQ3OvinQ70iBeQ9JGuPm_1B3n1KZkg@mail.gmail.com>

Marcos, isso ocorre apenas pra alguns destinos espec?ficos? Com outros n?o?

Na borda do cliente voc? j? conferiu se a sess?o est? fechada corretamente
com o tr?nsito?

E j? conferiu se algum filtro na borda dele n?o est? influenciando esses
destinos espec?ficos?


Alexandre Aleixo




Em ter., 4 de ago. de 2020 ?s 09:26, Marcos Silva <
marcos.silva at telium.com.br> escreveu:

> Bom dia pessoal,
>
> Trabalho numa empresa que fornece tr?nsito IP para clientes, me deparei
> com uma situa??o curiosa onde o cliente n?o consegue comunica??o com
> destinos especificos com origem de seu AS, destinos como empresas para
> fechar uma comunica??o VPN, a partir do AS dele ele n?o consegue uma
> simples comunica??o ICMP com o destino que se encontra aberto para
> receber os pacotes. J? se depararam com casos como este? O cliente se
> encontra nos primeiros passos do AS. Realizamos o propaga??o para nossas
> operadoras de transporte corretamente sem realizar nenhum bloqueio, e
> mesmo por outro transito o cliente tem o mesmo comportamento anormal.
>
>
> Atenciosamente,
>
>
> Marcos Silva
>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From wld.net1 at gmail.com  Tue Aug  4 14:36:49 2020
From: wld.net1 at gmail.com (Wagner Loula)
Date: Tue, 4 Aug 2020 14:36:49 -0300
Subject: [GTER] =?utf-8?q?Tr=C3=A2nsito_AS?=
In-Reply-To: <CAO4k365c-PhNApn_1o3njQ3OvinQ70iBeQ9JGuPm_1B3n1KZkg@mail.gmail.com>
References: <f1479c3e-acdd-c85d-7f10-20294f6e6582@telium.com.br>
 <CAO4k365c-PhNApn_1o3njQ3OvinQ70iBeQ9JGuPm_1B3n1KZkg@mail.gmail.com>
Message-ID: <CAJPN+XreNo5h1Wt0LAV9Cdgh4AcXvzYc2_crN2FPZ+4eZ2VF0g@mail.gmail.com>

est? com cara de ser algum filtro ou do seu lado, ou do lado do cliente

Em ter., 4 de ago. de 2020 ?s 11:49, Alexandre Aleixo | Opticalhost <
alexandre at opticalhost.com.br> escreveu:

> Marcos, isso ocorre apenas pra alguns destinos espec?ficos? Com outros n?o?
>
> Na borda do cliente voc? j? conferiu se a sess?o est? fechada corretamente
> com o tr?nsito?
>
> E j? conferiu se algum filtro na borda dele n?o est? influenciando esses
> destinos espec?ficos?
>
>
> Alexandre Aleixo
>
>
>
>
> Em ter., 4 de ago. de 2020 ?s 09:26, Marcos Silva <
> marcos.silva at telium.com.br> escreveu:
>
> > Bom dia pessoal,
> >
> > Trabalho numa empresa que fornece tr?nsito IP para clientes, me deparei
> > com uma situa??o curiosa onde o cliente n?o consegue comunica??o com
> > destinos especificos com origem de seu AS, destinos como empresas para
> > fechar uma comunica??o VPN, a partir do AS dele ele n?o consegue uma
> > simples comunica??o ICMP com o destino que se encontra aberto para
> > receber os pacotes. J? se depararam com casos como este? O cliente se
> > encontra nos primeiros passos do AS. Realizamos o propaga??o para nossas
> > operadoras de transporte corretamente sem realizar nenhum bloqueio, e
> > mesmo por outro transito o cliente tem o mesmo comportamento anormal.
> >
> >
> > Atenciosamente,
> >
> >
> > Marcos Silva
> >
> >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Att;
Wagner Loula
Analista de Redes
Fone: (87) 9 9177-5939

From bruno at openline.com.br  Tue Aug  4 15:04:44 2020
From: bruno at openline.com.br (Bruno Cabral)
Date: Tue, 4 Aug 2020 18:04:44 +0000
Subject: [GTER] =?iso-8859-1?q?Tr=E2nsito_AS?=
In-Reply-To: <f1479c3e-acdd-c85d-7f10-20294f6e6582@telium.com.br>
References: <f1479c3e-acdd-c85d-7f10-20294f6e6582@telium.com.br>
Message-ID: <RO1PR80MB3644E0D1DA5993659D6C67D4F54A0@RO1PR80MB3644.lamprd80.prod.outlook.com>

Ja encontrei e nao foi pouco

Ele tem outro transito? Ou cancelou outro transito recentemente? O outro transito cancelou os filtros do prefixo dele com os transitos deles?

Ele faz parte de algum PTT? Tive um cliente recente com bastante problema com a Ascenty, que funcionava quando este cliente anunciava no PTT SP mas nao funcionava quanto ele desligava SP e ligava o PTT RJ (migrou de SP para o RJ por questao de custos)

Ele fez o cadastro de geolocaliza??o do bloco dele?

[]s, !3runo Cabral

--
<http://f2link.f2b.com.br/impressora3d>Cursos e Consultoria BGP, OSPF e MPLS

________________________________
De: gter <gter-bounces at eng.registro.br> em nome de Marcos Silva <marcos.silva at telium.com.br>
Enviado: ter?a-feira, 4 de agosto de 2020 09:26
Para: gter at eng.registro.br <gter at eng.registro.br>
Assunto: [GTER] Tr?nsito AS

Bom dia pessoal,

Trabalho numa empresa que fornece tr?nsito IP para clientes, me deparei
com uma situa??o curiosa onde o cliente n?o consegue comunica??o com
destinos especificos com origem de seu AS, destinos como empresas para
fechar uma comunica??o VPN, a partir do AS dele ele n?o consegue uma
simples comunica??o ICMP com o destino que se encontra aberto para
receber os pacotes. J? se depararam com casos como este? O cliente se
encontra nos primeiros passos do AS. Realizamos o propaga??o para nossas
operadoras de transporte corretamente sem realizar nenhum bloqueio, e
mesmo por outro transito o cliente tem o mesmo comportamento anormal.


Atenciosamente,


Marcos Silva


--
gter list    https://eng.registro.br/mailman/listinfo/gter

From nielsenk at gmail.com  Thu Aug  6 08:18:54 2020
From: nielsenk at gmail.com (Nielsen Kaezer)
Date: Thu, 6 Aug 2020 08:18:54 -0300
Subject: [GTER] Femtocell alcatel Lucent
Message-ID: <CABJaL1qfDkFOLCn=1bq19BEQQ5rVAEnpwp64sYTAmhutOweVFQ@mail.gmail.com>

Prezados estamos com uma Femtocell da Claro da marca Alcatel Lucent que n?o
registra na Claro, nem em outro provedor nem na nosso onde temos manipulado
a saida por dois transitos diferentes.
O pessoal da claro se isentou e so informou as portas que necessitam estar
abertas.
Alguem usa ou j? usou esse trambolho ?

From thiago.rocha at bsd.com.br  Thu Aug  6 12:58:40 2020
From: thiago.rocha at bsd.com.br (Thiago@BSD)
Date: Thu, 6 Aug 2020 12:58:40 -0300
Subject: [GTER] Femtocell alcatel Lucent
In-Reply-To: <CABJaL1qfDkFOLCn=1bq19BEQQ5rVAEnpwp64sYTAmhutOweVFQ@mail.gmail.com>
References: <CABJaL1qfDkFOLCn=1bq19BEQQ5rVAEnpwp64sYTAmhutOweVFQ@mail.gmail.com>
Message-ID: <EBB343C4-FF5F-4CB2-B36F-6FC1A0EEC20A@bsd.com.br>



> On 6 Aug 2020, at 11:09, Nielsen Kaezer <nielsenk at gmail.com> wrote:
> 
> ?Prezados estamos com uma Femtocell da Claro da marca Alcatel Lucent que n?o
> registra na Claro, nem em outro provedor nem na nosso onde temos manipulado
> a saida por dois transitos diferentes.
> O pessoal da claro se isentou e so informou as portas que necessitam estar
> abertas.
> Alguem usa ou j? usou esse trambolho ?
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

Ol?, j? tive esse mesmo equipamento/marca/operadora, e funcionava apenas liberado o IP dele no firewall. Funcionou por v?rios anos sem problemas.

Esse equipamento j? funcionou antes?

Pelo relatado eu diria que deve estar configurado errado por parte dele da operadora.

From rodrigoa at gmail.com  Thu Aug  6 13:12:51 2020
From: rodrigoa at gmail.com (Rodrigo Almeida)
Date: Thu, 6 Aug 2020 13:12:51 -0300
Subject: [GTER] Perda de pacotes net/claro.
Message-ID: <CAMDLx1+Kjcj4iGBjeGhqrbLpL3zZ1pQ8-6ztBrebL_hf7zxOVg@mail.gmail.com>

Prezados,

Algu?m mais est? enfrentando problemas com net/claro residencial no Rio de
Janeiro? Desde ter?a-feira est? com uma perda de pacotes absurda dentro da
rede virtua.


               *   Packets*               *Pings*

* Host*
                 * Loss%   Snt   Last   Avg  Best  Wrst StDev*

 1. 192.168.0.1
                  0.0%   170    1.2   1.5   0.8   7.5   0.9

 2. bd7ab001.virtua.com.br
                29.2%   169   10.0  12.3   7.4  75.4   7.9

 3. c91121e2.virtua.com.br
                28.0%   169   26.5  13.5   7.5 112.8  11.2

 4. c91122d5.virtua.com.br
                25.6%   169   12.3  26.4   6.6 172.3  38.3

 5. c9110009.virtua.com.br
                29.2%   169   10.6  18.2   7.9 123.0  18.6

 6. c9112442.virtua.com.br
                32.5%   169   12.1  11.9   7.9  68.8   6.3

 7. 192.168.159.21
                33.1%   169   11.4  12.0   8.2  28.4   3.4

 8. 186-192-81-5.prt.globo.com
                33.1%   169   15.6  11.7   5.3  35.1   4.4

From erigler at gmail.com  Thu Aug  6 15:06:20 2020
From: erigler at gmail.com (Eduardo Rigler)
Date: Thu, 6 Aug 2020 15:06:20 -0300
Subject: [GTER] Perda de pacotes net/claro.
In-Reply-To: <CAMDLx1+Kjcj4iGBjeGhqrbLpL3zZ1pQ8-6ztBrebL_hf7zxOVg@mail.gmail.com>
References: <CAMDLx1+Kjcj4iGBjeGhqrbLpL3zZ1pQ8-6ztBrebL_hf7zxOVg@mail.gmail.com>
Message-ID: <CA+gOtKDnT3g+09-3_XAT5sJ06XYAvxwMwPqQvqqL-CPsX4niVg@mail.gmail.com>

Como est?o seus sinais (niveis.virtua.com.br) ?

Em qui., 6 de ago. de 2020 ?s 15:02, Rodrigo Almeida <rodrigoa at gmail.com>
escreveu:

> Prezados,
>
> Algu?m mais est? enfrentando problemas com net/claro residencial no Rio de
> Janeiro? Desde ter?a-feira est? com uma perda de pacotes absurda dentro da
> rede virtua.
>
>
>                *   Packets*               *Pings*
>
> * Host*
>                  * Loss%   Snt   Last   Avg  Best  Wrst StDev*
>
>  1. 192.168.0.1
>                   0.0%   170    1.2   1.5   0.8   7.5   0.9
>
>  2. bd7ab001.virtua.com.br
>                 29.2%   169   10.0  12.3   7.4  75.4   7.9
>
>  3. c91121e2.virtua.com.br
>                 28.0%   169   26.5  13.5   7.5 112.8  11.2
>
>  4. c91122d5.virtua.com.br
>                 25.6%   169   12.3  26.4   6.6 172.3  38.3
>
>  5. c9110009.virtua.com.br
>                 29.2%   169   10.6  18.2   7.9 123.0  18.6
>
>  6. c9112442.virtua.com.br
>                 32.5%   169   12.1  11.9   7.9  68.8   6.3
>
>  7. 192.168.159.21
>                 33.1%   169   11.4  12.0   8.2  28.4   3.4
>
>  8. 186-192-81-5.prt.globo.com
>                 33.1%   169   15.6  11.7   5.3  35.1   4.4
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From rodrigoa at gmail.com  Thu Aug  6 15:40:32 2020
From: rodrigoa at gmail.com (Rodrigo Almeida)
Date: Thu, 6 Aug 2020 15:40:32 -0300
Subject: [GTER] Perda de pacotes net/claro.
In-Reply-To: <CA+gOtKDnT3g+09-3_XAT5sJ06XYAvxwMwPqQvqqL-CPsX4niVg@mail.gmail.com>
References: <CAMDLx1+Kjcj4iGBjeGhqrbLpL3zZ1pQ8-6ztBrebL_hf7zxOVg@mail.gmail.com>
 <CA+gOtKDnT3g+09-3_XAT5sJ06XYAvxwMwPqQvqqL-CPsX4niVg@mail.gmail.com>
Message-ID: <CAMDLx1+efq8z3H6qHTGRYGQC4oG98uV8XTwy=dNqGXJkNaP_qw@mail.gmail.com>

Est?o ok.

Sinal TXSinal RXSNR DSSNR UPReceive Power
45.0 -4.5 39.5 34.0 0


On Thu, Aug 6, 2020 at 3:07 PM Eduardo Rigler <erigler at gmail.com> wrote:

> Como est?o seus sinais (niveis.virtua.com.br) ?
>
> Em qui., 6 de ago. de 2020 ?s 15:02, Rodrigo Almeida <rodrigoa at gmail.com>
> escreveu:
>
> > Prezados,
> >
> > Algu?m mais est? enfrentando problemas com net/claro residencial no Rio
> de
> > Janeiro? Desde ter?a-feira est? com uma perda de pacotes absurda dentro
> da
> > rede virtua.
> >
> >
> >                *   Packets*               *Pings*
> >
> > * Host*
> >                  * Loss%   Snt   Last   Avg  Best  Wrst StDev*
> >
> >  1. 192.168.0.1
> >                   0.0%   170    1.2   1.5   0.8   7.5   0.9
> >
> >  2. bd7ab001.virtua.com.br
> >                 29.2%   169   10.0  12.3   7.4  75.4   7.9
> >
> >  3. c91121e2.virtua.com.br
> >                 28.0%   169   26.5  13.5   7.5 112.8  11.2
> >
> >  4. c91122d5.virtua.com.br
> >                 25.6%   169   12.3  26.4   6.6 172.3  38.3
> >
> >  5. c9110009.virtua.com.br
> >                 29.2%   169   10.6  18.2   7.9 123.0  18.6
> >
> >  6. c9112442.virtua.com.br
> >                 32.5%   169   12.1  11.9   7.9  68.8   6.3
> >
> >  7. 192.168.159.21
> >                 33.1%   169   11.4  12.0   8.2  28.4   3.4
> >
> >  8. 186-192-81-5.prt.globo.com
> >                 33.1%   169   15.6  11.7   5.3  35.1   4.4
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From schererpi at gmail.com  Thu Aug  6 16:13:03 2020
From: schererpi at gmail.com (Pietro Scherer)
Date: Thu, 6 Aug 2020 16:13:03 -0300
Subject: [GTER] =?utf-8?q?Problemas_de_Geolocaliza=C3=A7=C3=A3o?=
Message-ID: <CAE-W7i79pq7NsBgfHJ=fG9ONEjb+aR-Db477fmx7atr3eswODg@mail.gmail.com>

Ol? pessoal, tudo bem?

Eis mais um e-mail sobre problemas de geolocaliza??o em blocos IP.

Estou enfrentando problemas em dois ASNs "novinhos em folha". Um deles est?
com problemas no jogo PUBG (vers?o para plataforma Steam), e ambos t?m
problemas ao acessar o site do SPC:

https://sistema.spc.org.br/spc/controleacesso/autenticacao/entry.action

J? solicitei o ajuste no Maxmind, db-ip, ip2location, entre outros. Fora
isso, fiz cadastro no PeeringDB, IRR TC, etc. Em todos eles as informa??es
de geolocaliza??o aparecem corretamente, mas os problemas citados acima
persistem.

Algu?m com o mesmo problema? Al?m disso, indicam alguma outra base para
solicitar a corre??o?

Desde j? agrade?o.
Atenciosamente,
-- 
*__*

*Pietro Scherer*

From diegofenner at gmail.com  Thu Aug  6 20:22:52 2020
From: diegofenner at gmail.com (Diego Fenner)
Date: Thu, 6 Aug 2020 20:22:52 -0300
Subject: [GTER] Perda de pacotes net/claro.
In-Reply-To: <CAMDLx1+efq8z3H6qHTGRYGQC4oG98uV8XTwy=dNqGXJkNaP_qw@mail.gmail.com>
References: <CAMDLx1+Kjcj4iGBjeGhqrbLpL3zZ1pQ8-6ztBrebL_hf7zxOVg@mail.gmail.com>
 <CA+gOtKDnT3g+09-3_XAT5sJ06XYAvxwMwPqQvqqL-CPsX4niVg@mail.gmail.com>
 <CAMDLx1+efq8z3H6qHTGRYGQC4oG98uV8XTwy=dNqGXJkNaP_qw@mail.gmail.com>
Message-ID: <CAOLfhk4EjE6sqn-AzjGdmx4Z0aksDudDxURTHvxBhxc2DwTT6Q@mail.gmail.com>

Ru?do, abra chamado solicitando limpeza de ru?do. se poss?vel, identificar
os hor?rios que est? pior, vai facilitar muito o trabalho do pessoal que
vai a campo.

Em qui., 6 de ago. de 2020 ?s 15:41, Rodrigo Almeida <rodrigoa at gmail.com>
escreveu:

> Est?o ok.
>
> Sinal TXSinal RXSNR DSSNR UPReceive Power
> 45.0 -4.5 39.5 34.0 0
>
>
> On Thu, Aug 6, 2020 at 3:07 PM Eduardo Rigler <erigler at gmail.com> wrote:
>
> > Como est?o seus sinais (niveis.virtua.com.br) ?
> >
> > Em qui., 6 de ago. de 2020 ?s 15:02, Rodrigo Almeida <rodrigoa at gmail.com
> >
> > escreveu:
> >
> > > Prezados,
> > >
> > > Algu?m mais est? enfrentando problemas com net/claro residencial no Rio
> > de
> > > Janeiro? Desde ter?a-feira est? com uma perda de pacotes absurda dentro
> > da
> > > rede virtua.
> > >
> > >
> > >                *   Packets*               *Pings*
> > >
> > > * Host*
> > >                  * Loss%   Snt   Last   Avg  Best  Wrst StDev*
> > >
> > >  1. 192.168.0.1
> > >                   0.0%   170    1.2   1.5   0.8   7.5   0.9
> > >
> > >  2. bd7ab001.virtua.com.br
> > >                 29.2%   169   10.0  12.3   7.4  75.4   7.9
> > >
> > >  3. c91121e2.virtua.com.br
> > >                 28.0%   169   26.5  13.5   7.5 112.8  11.2
> > >
> > >  4. c91122d5.virtua.com.br
> > >                 25.6%   169   12.3  26.4   6.6 172.3  38.3
> > >
> > >  5. c9110009.virtua.com.br
> > >                 29.2%   169   10.6  18.2   7.9 123.0  18.6
> > >
> > >  6. c9112442.virtua.com.br
> > >                 32.5%   169   12.1  11.9   7.9  68.8   6.3
> > >
> > >  7. 192.168.159.21
> > >                 33.1%   169   11.4  12.0   8.2  28.4   3.4
> > >
> > >  8. 186-192-81-5.prt.globo.com
> > >                 33.1%   169   15.6  11.7   5.3  35.1   4.4
> > > --
> > > 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
>


-- 
Best regards.
Atenciosamente.

diegofenner at gmail.com

diego.fenner

+55 47 99997-9069

From nielsenk at gmail.com  Fri Aug  7 09:34:34 2020
From: nielsenk at gmail.com (Nielsen Kaezer)
Date: Fri, 7 Aug 2020 09:34:34 -0300
Subject: [GTER] Femtocell alcatel Lucent
Message-ID: <CABJaL1qDerKrtEWnaOWiE_TApAF8zOZkWzFsehzvk9AnUUm1+Q@mail.gmail.com>

Thiago no outro provedor que tem link no local a mesma fica intermitente,
as vezes dias sem funcionar.
Conosco nunca funcionou, ela recebe IP via DHCP na sua "WAN" ?
Todas portas necess?rias para o equipamento d?o como abertas em N testes
que fizemos,

From jsirota at nic.br  Fri Aug  7 11:05:38 2020
From: jsirota at nic.br (Julio Sirota)
Date: Fri, 7 Aug 2020 11:05:38 -0300
Subject: [GTER] =?utf-8?q?Quais_IX_ainda_n=C3=A3o_tem_communities=3F?=
In-Reply-To: <9ce2b59a-a167-8fde-01b2-9e775eaa98ac@nic.br>
References: <CAKAeHyE5ggS1iRyA6Ax_R3zQKV-AZh9umb2Eoi7dASwPLfDWnw@mail.gmail.com>
 <484ae4c9-60a5-af5e-49da-98714df1a879@gmail.com>
 <188ee3f7-442d-5180-cd52-6174733066b0@nic.br>
 <abfe3421-0d5f-0b3f-f367-159a2279c755@nic.br>
 <70d7f18d-f327-2789-3512-589766d5e4ea@nic.br>
 <f4b27eae-6e3e-3837-8e24-e8eb55a5d1f8@nic.br>
 <ff49e6ae-68e2-727a-efec-881a48bd0aff@nic.br>
 <9ce2b59a-a167-8fde-01b2-9e775eaa98ac@nic.br>
Message-ID: <d58a0799-ddb8-7777-a29e-ccebee8cef30@nic.br>

Finalizamos hoje a implanta??o do tratamento de communities BGP em todas
as localidades do IX.br.

Novas localidades ir?o nascer com esta funcionalidade tamnb?m.

NIC.br | Julio Sirota
Gerente de Infraestrutura
IX.br
+55 11 5509-3546 / 99197-5754
www.nic.br <http://nic.br>


Em 17/07/2020 09:34, Julio Sirota escreveu:
> Mais uma localidade com communities em funcionamento: Maring?/PR
>
> NIC.br | Julio Sirota
> Gerente de Infraestrutura
> IX.br
> +55 11 5509-3546 / 99197-5754
> www.nic.br <http://nic.br>
>
>
> Em 03/07/2020 12:13, Julio Sirota escreveu:
>> Mais uma localidade com communities em funcionamento: Bel?m/PA
>>
>> NIC.br | Julio Sirota
>> Gerente de Infraestrutura
>> IX.br
>> +55 11 5509-3546 / 99197-5754
>> www.nic.br <http://nic.br>
>>
>>
>> Em 01/07/2020 14:20, Julio Sirota escreveu:
>>> Mais uma localidade com communities em funcionamento: Goi?nia/GO
>>>
>>> NIC.br | Julio Sirota
>>> Gerente de Infraestrutura
>>> IX.br
>>> +55 11 5509-3546 / 99197-5754
>>> www.nic.br <http://nic.br>
>>>
>>>
>>> Em 25/06/2020 16:58, Julio Sirota escreveu:
>>>> Mais uma localidade com communities em funcionamento: Campina Grande/PB
>>>>
>>>> NIC.br | Julio Sirota
>>>> Gerente de Infraestrutura
>>>> IX.br
>>>> +55 11 5509-3546 / 99197-5754
>>>> www.nic.br <http://nic.br>
>>>>
>>>>
>>>> Em 23/06/2020 11:58, Julio Sirota escreveu:
>>>>> Mais uma localidade com communities em funcionamento: Recife/PE
>>>>>
>>>>> NIC.br | Julio Sirota
>>>>> Gerente de Infraestrutura
>>>>> IX.br
>>>>> +55 11 5509-3546 / 99197-5754
>>>>> www.nic.br <http://nic.br>
>>>>>
>>>>>
>>>>> Em 22/06/2020 12:32, Julio Sirota escreveu:
>>>>>> Atualmente temos tratamento de communities nas seguintes localidades do
>>>>>> IX.br:
>>>>>>
>>>>>> Belo Horizonte/MG
>>>>>> Bras?lia/DF
>>>>>> Campinas/SP
>>>>>> Curitiba/PR
>>>>>> Florian?polis/SC
>>>>>> Fortaleza/CE
>>>>>> Jo?o Pessoa/PB
>>>>>> Lajeado/RS
>>>>>> Londrina/PR
>>>>>> Manaus/AM
>>>>>> Natal/RN
>>>>>> Porto Alegre/RS
>>>>>> Rio de Janeiro/RJ
>>>>>> Salvador/BA
>>>>>> Santa Maria/RS
>>>>>> S?o Paulo/SP
>>>>>> Vit?ria/ES
>>>>>> Macei?/AL
>>>>>> Teresina/PI
>>>>>> S?o Lu?s/MA
>>>>>> Campo Grande/MS
>>>>>> Cascavel/PR
>>>>>>
>>>>>> Em breve teremos mais algumas !
>>>>>>
>>>>>> NIC.br | Julio Sirota
>>>>>> Gerente de Infraestrutura
>>>>>> IX.br
>>>>>> +55 11 5509-3546 / 99197-5754
>>>>>> www.nic.br <http://nic.br>
>>>>>>
>>>>>>
>>>>>> Em 19/06/2020 20:34, Fernando Frediani escreveu:
>>>>>>> Andr?, de acordo com informa??o aqui -
>>>>>>> https://wiki.brasilpeeringforum.org/w/Lista_de_Communities_BGP#IX.br -
>>>>>>> existem 14 IX que possuem suporte ? communities. Seria interessante
>>>>>>> caso algum novo tenha sido adicionado atualizar a p?gina.
>>>>>>>
>>>>>>> Fernando Frediani
>>>>>>>
>>>>>>> On 19/06/2020 18:50, Andre Almeida wrote:
>>>>>>>> Amigos, do IX-BR, algu?m sabe quais n?o tem (ou se a lista for muito
>>>>>>>> grande, dizer quais tem) as communities de controle de tr?fego
>>>>>>>> aplicadas?
>>>>>>>>
>>>>>>>> Obrigado!
>>>>>>>>
>>>>>>>> Andre
>>>>>>>> -- 
>>>>>>>> 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
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

From thiago.rocha at bsd.com.br  Fri Aug  7 11:15:27 2020
From: thiago.rocha at bsd.com.br (Thiago@BSD)
Date: Fri, 7 Aug 2020 11:15:27 -0300
Subject: [GTER] Femtocell alcatel Lucent
In-Reply-To: <CABJaL1qDerKrtEWnaOWiE_TApAF8zOZkWzFsehzvk9AnUUm1+Q@mail.gmail.com>
References: <CABJaL1qDerKrtEWnaOWiE_TApAF8zOZkWzFsehzvk9AnUUm1+Q@mail.gmail.com>
Message-ID: <60809B4C-F438-47C5-9422-C1E992488B31@bsd.com.br>

Eu n?o tenho mais o aparelho (a empresa optou por trocar de operadora), mas na ?poca foi apenas liberar o IP que a femtocell recebia via DHCP, simples assim.

Por isso que sugeri que seria problema de config por parte da operadora, mas se ? intermitente (em outro local) fica bem mais complexo.

Sinto n?o poder ajudar mais.

From elizandro at pachecotecnologia.net  Fri Aug  7 12:55:36 2020
From: elizandro at pachecotecnologia.net (ElizandroPacheco [ NextHop Solutions ])
Date: Fri, 07 Aug 2020 15:55:36 +0000
Subject: [GTER] =?utf-8?q?Problemas_de_Geolocaliza=C3=A7=C3=A3o?=
In-Reply-To: <CAE-W7i79pq7NsBgfHJ=fG9ONEjb+aR-Db477fmx7atr3eswODg@mail.gmail.com>
References: <CAE-W7i79pq7NsBgfHJ=fG9ONEjb+aR-Db477fmx7atr3eswODg@mail.gmail.com>
Message-ID: <em4c1b3f29-8c85-49b9-bb7e-4626cb1ab786@elliot>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

O que notei em alguns servi?os ? que eles n?o fazem uma consulta em
tempo real disso, via uma api ou sei l? oq...

Apenas atualizam o banco de tempos em tempos, e com isso alguns servi?os
levam at? semanas pra atualizar, mesmo no site mostrando j? estar
atualizado.

Me parece, em alguns casos, ser um processo manual ou peri?dico..

Nos casos que tive, alguns at? tentei contado, apenas de um tive retorno
e mesmo assim o retorno foi: - Aguarde alguns dias ap?s a atualiza??o.


Elizandro Pacheco
NextHop Solutions

- ------ Mensagem original ------
De: "Pietro Scherer" <schererpi at gmail.com>
Para: gter at eng.registro.br
Enviado(s): 06/08/2020 16:13:03
Assunto: [GTER] Problemas de Geolocaliza??o

>Ol? pessoal, tudo bem?
>
>Eis mais um e-mail sobre problemas de geolocaliza??o em blocos IP.
>
>Estou enfrentando problemas em dois ASNs "novinhos em folha". Um deles est?
>com problemas no jogo PUBG (vers?o para plataforma Steam), e ambos t?m
>problemas ao acessar o site do SPC:
>
>https://sistema.spc.org.br/spc/controleacesso/autenticacao/entry.action
>
>J? solicitei o ajuste no Maxmind, db-ip, ip2location, entre outros. Fora
>isso, fiz cadastro no PeeringDB, IRR TC, etc. Em todos eles as informa??es
>de geolocaliza??o aparecem corretamente, mas os problemas citados acima
>persistem.
>
>Algu?m com o mesmo problema? Al?m disso, indicam alguma outra base para
>solicitar a corre??o?
>
>Desde j? agrade?o.
>Atenciosamente,
>--
>*__*
>
>*Pietro Scherer*
>--
    https://eng.registro.br/mailman/listinfo/gter
-----BEGIN PGP SIGNATURE-----
Version: BCPG C# v1.8.6.0

iMAEAQEIACoFAl8teX8jHCA8ZWxpemFuZHJvQHBhY2hlY290ZWNub2xvZ2lhLm5l
dD4ACgkQ0maguz4L8yNRpwP/ZykClC2HR2RtkKKlLPN4X4xRYlpGLAMPu6EVHBu+
KzOVDWg4HybeAs+1xycLMctcL66uWgeo+INPwEhlO66Q9ObI5hWfK2zX6XvAW2Vw
WZfKkVvr70u5wbkgI9OnUR3FCtuwbEkB1Jqme2277Nua29QToT9Lq6fqym3KQxm7
HUw=
=/595
-----END PGP SIGNATURE-----

From fischerdouglas at gmail.com  Fri Aug  7 13:06:17 2020
From: fischerdouglas at gmail.com (Douglas Fischer)
Date: Fri, 7 Aug 2020 13:06:17 -0300
Subject: [GTER] =?utf-8?q?Quais_IX_ainda_n=C3=A3o_tem_communities=3F?=
In-Reply-To: <d58a0799-ddb8-7777-a29e-ccebee8cef30@nic.br>
References: <CAKAeHyE5ggS1iRyA6Ax_R3zQKV-AZh9umb2Eoi7dASwPLfDWnw@mail.gmail.com>
 <484ae4c9-60a5-af5e-49da-98714df1a879@gmail.com>
 <188ee3f7-442d-5180-cd52-6174733066b0@nic.br>
 <abfe3421-0d5f-0b3f-f367-159a2279c755@nic.br>
 <70d7f18d-f327-2789-3512-589766d5e4ea@nic.br>
 <f4b27eae-6e3e-3837-8e24-e8eb55a5d1f8@nic.br>
 <ff49e6ae-68e2-727a-efec-881a48bd0aff@nic.br>
 <9ce2b59a-a167-8fde-01b2-9e775eaa98ac@nic.br>
 <d58a0799-ddb8-7777-a29e-ccebee8cef30@nic.br>
Message-ID: <CAKEr4RTmtOpC7BeyWGxigrRxG114_qRWT0W9386Ha7zwkQwFjA@mail.gmail.com>

?

Em sex., 7 de ago. de 2020 ?s 11:06, Julio Sirota <jsirota at nic.br> escreveu:

> Finalizamos hoje a implanta??o do tratamento de communities BGP em todas
> as localidades do IX.br.
>
> Novas localidades ir?o nascer com esta funcionalidade tamnb?m.
>
> NIC.br | Julio Sirota
> Gerente de Infraestrutura
> IX.br
> +55 11 5509-3546 / 99197-5754
> www.nic.br <http://nic.br>
>
>
> Em 17/07/2020 09:34, Julio Sirota escreveu:
> > Mais uma localidade com communities em funcionamento: Maring?/PR
> >
> > NIC.br | Julio Sirota
> > Gerente de Infraestrutura
> > IX.br
> > +55 11 5509-3546 / 99197-5754
> > www.nic.br <http://nic.br>
> >
> >
> > Em 03/07/2020 12:13, Julio Sirota escreveu:
> >> Mais uma localidade com communities em funcionamento: Bel?m/PA
> >>
> >> NIC.br | Julio Sirota
> >> Gerente de Infraestrutura
> >> IX.br
> >> +55 11 5509-3546 / 99197-5754
> >> www.nic.br <http://nic.br>
> >>
> >>
> >> Em 01/07/2020 14:20, Julio Sirota escreveu:
> >>> Mais uma localidade com communities em funcionamento: Goi?nia/GO
> >>>
> >>> NIC.br | Julio Sirota
> >>> Gerente de Infraestrutura
> >>> IX.br
> >>> +55 11 5509-3546 / 99197-5754
> >>> www.nic.br <http://nic.br>
> >>>
> >>>
> >>> Em 25/06/2020 16:58, Julio Sirota escreveu:
> >>>> Mais uma localidade com communities em funcionamento: Campina
> Grande/PB
> >>>>
> >>>> NIC.br | Julio Sirota
> >>>> Gerente de Infraestrutura
> >>>> IX.br
> >>>> +55 11 5509-3546 / 99197-5754
> >>>> www.nic.br <http://nic.br>
> >>>>
> >>>>
> >>>> Em 23/06/2020 11:58, Julio Sirota escreveu:
> >>>>> Mais uma localidade com communities em funcionamento: Recife/PE
> >>>>>
> >>>>> NIC.br | Julio Sirota
> >>>>> Gerente de Infraestrutura
> >>>>> IX.br
> >>>>> +55 11 5509-3546 / 99197-5754
> >>>>> www.nic.br <http://nic.br>
> >>>>>
> >>>>>
> >>>>> Em 22/06/2020 12:32, Julio Sirota escreveu:
> >>>>>> Atualmente temos tratamento de communities nas seguintes
> localidades do
> >>>>>> IX.br:
> >>>>>>
> >>>>>> Belo Horizonte/MG
> >>>>>> Bras?lia/DF
> >>>>>> Campinas/SP
> >>>>>> Curitiba/PR
> >>>>>> Florian?polis/SC
> >>>>>> Fortaleza/CE
> >>>>>> Jo?o Pessoa/PB
> >>>>>> Lajeado/RS
> >>>>>> Londrina/PR
> >>>>>> Manaus/AM
> >>>>>> Natal/RN
> >>>>>> Porto Alegre/RS
> >>>>>> Rio de Janeiro/RJ
> >>>>>> Salvador/BA
> >>>>>> Santa Maria/RS
> >>>>>> S?o Paulo/SP
> >>>>>> Vit?ria/ES
> >>>>>> Macei?/AL
> >>>>>> Teresina/PI
> >>>>>> S?o Lu?s/MA
> >>>>>> Campo Grande/MS
> >>>>>> Cascavel/PR
> >>>>>>
> >>>>>> Em breve teremos mais algumas !
> >>>>>>
> >>>>>> NIC.br | Julio Sirota
> >>>>>> Gerente de Infraestrutura
> >>>>>> IX.br
> >>>>>> +55 11 5509-3546 / 99197-5754
> >>>>>> www.nic.br <http://nic.br>
> >>>>>>
> >>>>>>
> >>>>>> Em 19/06/2020 20:34, Fernando Frediani escreveu:
> >>>>>>> Andr?, de acordo com informa??o aqui -
> >>>>>>>
> https://wiki.brasilpeeringforum.org/w/Lista_de_Communities_BGP#IX.br -
> >>>>>>> existem 14 IX que possuem suporte ? communities. Seria interessante
> >>>>>>> caso algum novo tenha sido adicionado atualizar a p?gina.
> >>>>>>>
> >>>>>>> Fernando Frediani
> >>>>>>>
> >>>>>>> On 19/06/2020 18:50, Andre Almeida wrote:
> >>>>>>>> Amigos, do IX-BR, algu?m sabe quais n?o tem (ou se a lista for
> muito
> >>>>>>>> grande, dizer quais tem) as communities de controle de tr?fego
> >>>>>>>> aplicadas?
> >>>>>>>>
> >>>>>>>> Obrigado!
> >>>>>>>>
> >>>>>>>> Andre
> >>>>>>>> --
> >>>>>>>> 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
> >> --
> >> 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
>


-- 
Douglas Fernando Fischer
Eng? de Controle e Automa??o

From schererpi at gmail.com  Fri Aug  7 16:43:54 2020
From: schererpi at gmail.com (Pietro Scherer)
Date: Fri, 7 Aug 2020 16:43:54 -0300
Subject: [GTER] =?utf-8?q?Problemas_de_Geolocaliza=C3=A7=C3=A3o?=
In-Reply-To: <em4c1b3f29-8c85-49b9-bb7e-4626cb1ab786@elliot>
References: <CAE-W7i79pq7NsBgfHJ=fG9ONEjb+aR-Db477fmx7atr3eswODg@mail.gmail.com>
 <em4c1b3f29-8c85-49b9-bb7e-4626cb1ab786@elliot>
Message-ID: <1163CF68-1A02-4528-8326-DBBE233985AF@gmail.com>

Obrigado pelo retorno Elizandro!

> Me parece, em alguns casos, ser um processo manual ou peri?dico..


Cogitei essa possibilidade. Vou aguardar mais alguns dias e qualquer novidade eu jogo aqui.

Atenciosamente,

Pietro Scherer
+55 55 99933-4218
Skype: pietroscherer
https://about.me/pietroscherer




> Em 7 de ago de 2020, ?(s) 12:55, ElizandroPacheco [ NextHop Solutions ] <elizandro at pachecotecnologia.net> escreveu:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> O que notei em alguns servi?os ? que eles n?o fazem uma consulta em
> tempo real disso, via uma api ou sei l? oq...
> 
> Apenas atualizam o banco de tempos em tempos, e com isso alguns servi?os
> levam at? semanas pra atualizar, mesmo no site mostrando j? estar
> atualizado.
> 
> Me parece, em alguns casos, ser um processo manual ou peri?dico..
> 
> Nos casos que tive, alguns at? tentei contado, apenas de um tive retorno
> e mesmo assim o retorno foi: - Aguarde alguns dias ap?s a atualiza??o.
> 
> 
> Elizandro Pacheco
> NextHop Solutions
> 
> - ------ Mensagem original ------
> De: "Pietro Scherer" <schererpi at gmail.com>
> Para: gter at eng.registro.br
> Enviado(s): 06/08/2020 16:13:03
> Assunto: [GTER] Problemas de Geolocaliza??o
> 
>> Ol? pessoal, tudo bem?
>> 
>> Eis mais um e-mail sobre problemas de geolocaliza??o em blocos IP.
>> 
>> Estou enfrentando problemas em dois ASNs "novinhos em folha". Um deles est?
>> com problemas no jogo PUBG (vers?o para plataforma Steam), e ambos t?m
>> problemas ao acessar o site do SPC:
>> 
>> https://sistema.spc.org.br/spc/controleacesso/autenticacao/entry.action
>> 
>> J? solicitei o ajuste no Maxmind, db-ip, ip2location, entre outros. Fora
>> isso, fiz cadastro no PeeringDB, IRR TC, etc. Em todos eles as informa??es
>> de geolocaliza??o aparecem corretamente, mas os problemas citados acima
>> persistem.
>> 
>> Algu?m com o mesmo problema? Al?m disso, indicam alguma outra base para
>> solicitar a corre??o?
>> 
>> Desde j? agrade?o.
>> Atenciosamente,
>> --
>> *__*
>> 
>> *Pietro Scherer*
>> --
>   https://eng.registro.br/mailman/listinfo/gter
> -----BEGIN PGP SIGNATURE-----
> Version: BCPG C# v1.8.6.0
> 
> iMAEAQEIACoFAl8teX8jHCA8ZWxpemFuZHJvQHBhY2hlY290ZWNub2xvZ2lhLm5l
> dD4ACgkQ0maguz4L8yNRpwP/ZykClC2HR2RtkKKlLPN4X4xRYlpGLAMPu6EVHBu+
> KzOVDWg4HybeAs+1xycLMctcL66uWgeo+INPwEhlO66Q9ObI5hWfK2zX6XvAW2Vw
> WZfKkVvr70u5wbkgI9OnUR3FCtuwbEkB1Jqme2277Nua29QToT9Lq6fqym3KQxm7
> HUw=
> =/595
> -----END PGP SIGNATURE-----
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter


From sup.rafaelgaldino at gmail.com  Fri Aug  7 20:35:57 2020
From: sup.rafaelgaldino at gmail.com (Rafael Galdino)
Date: Fri, 7 Aug 2020 20:35:57 -0300
Subject: [GTER] =?utf-8?q?Problemas_de_Geolocaliza=C3=A7=C3=A3o?=
In-Reply-To: <1163CF68-1A02-4528-8326-DBBE233985AF@gmail.com>
References: <CAE-W7i79pq7NsBgfHJ=fG9ONEjb+aR-Db477fmx7atr3eswODg@mail.gmail.com>
 <em4c1b3f29-8c85-49b9-bb7e-4626cb1ab786@elliot>
 <1163CF68-1A02-4528-8326-DBBE233985AF@gmail.com>
Message-ID: <CAPefbKornnaaU9gR4Qx6M+wcBzsWVS7ExbJOzwquyF56_-AfAw@mail.gmail.com>

eu tive problema com alguns clientes meus de S?o Paulo que a geolocaliza??o
estava dando Minas Gerais.
Fiz a corre??o no Maxmind, por?m entrei em contato contato com a globo para
eles atualizarem por l? antes.
fui prontamente atendido, caso queiram resolver esse problema falem com:
nedimar.turatti at g.globo
ele me informou que eu poderia passar o contato para essa corre??o.

Em sex., 7 de ago. de 2020 ?s 16:44, Pietro Scherer <schererpi at gmail.com>
escreveu:

> Obrigado pelo retorno Elizandro!
>
> > Me parece, em alguns casos, ser um processo manual ou peri?dico..
>
>
> Cogitei essa possibilidade. Vou aguardar mais alguns dias e qualquer
> novidade eu jogo aqui.
>
> Atenciosamente,
>
> Pietro Scherer
> +55 55 99933-4218
> Skype: pietroscherer
> https://about.me/pietroscherer
>
>
>
>
> > Em 7 de ago de 2020, ?(s) 12:55, ElizandroPacheco [ NextHop Solutions ] <
> elizandro at pachecotecnologia.net> escreveu:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > O que notei em alguns servi?os ? que eles n?o fazem uma consulta em
> > tempo real disso, via uma api ou sei l? oq...
> >
> > Apenas atualizam o banco de tempos em tempos, e com isso alguns servi?os
> > levam at? semanas pra atualizar, mesmo no site mostrando j? estar
> > atualizado.
> >
> > Me parece, em alguns casos, ser um processo manual ou peri?dico..
> >
> > Nos casos que tive, alguns at? tentei contado, apenas de um tive retorno
> > e mesmo assim o retorno foi: - Aguarde alguns dias ap?s a atualiza??o.
> >
> >
> > Elizandro Pacheco
> > NextHop Solutions
> >
> > - ------ Mensagem original ------
> > De: "Pietro Scherer" <schererpi at gmail.com>
> > Para: gter at eng.registro.br
> > Enviado(s): 06/08/2020 16:13:03
> > Assunto: [GTER] Problemas de Geolocaliza??o
> >
> >> Ol? pessoal, tudo bem?
> >>
> >> Eis mais um e-mail sobre problemas de geolocaliza??o em blocos IP.
> >>
> >> Estou enfrentando problemas em dois ASNs "novinhos em folha". Um deles
> est?
> >> com problemas no jogo PUBG (vers?o para plataforma Steam), e ambos t?m
> >> problemas ao acessar o site do SPC:
> >>
> >> https://sistema.spc.org.br/spc/controleacesso/autenticacao/entry.action
> >>
> >> J? solicitei o ajuste no Maxmind, db-ip, ip2location, entre outros. Fora
> >> isso, fiz cadastro no PeeringDB, IRR TC, etc. Em todos eles as
> informa??es
> >> de geolocaliza??o aparecem corretamente, mas os problemas citados acima
> >> persistem.
> >>
> >> Algu?m com o mesmo problema? Al?m disso, indicam alguma outra base para
> >> solicitar a corre??o?
> >>
> >> Desde j? agrade?o.
> >> Atenciosamente,
> >> --
> >> *__*
> >>
> >> *Pietro Scherer*
> >> --
> >   https://eng.registro.br/mailman/listinfo/gter
> > -----BEGIN PGP SIGNATURE-----
> > Version: BCPG C# v1.8.6.0
> >
> > iMAEAQEIACoFAl8teX8jHCA8ZWxpemFuZHJvQHBhY2hlY290ZWNub2xvZ2lhLm5l
> > dD4ACgkQ0maguz4L8yNRpwP/ZykClC2HR2RtkKKlLPN4X4xRYlpGLAMPu6EVHBu+
> > KzOVDWg4HybeAs+1xycLMctcL66uWgeo+INPwEhlO66Q9ObI5hWfK2zX6XvAW2Vw
> > WZfKkVvr70u5wbkgI9OnUR3FCtuwbEkB1Jqme2277Nua29QToT9Lq6fqym3KQxm7
> > HUw=
> > =/595
> > -----END PGP SIGNATURE-----
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 


*Rafael Galdino*


*http://Suporte.network <http://Suporte.network>*

       contato at suporte.network

      Phone:
*+55 (83) 98211-9090*


*Whatsapp: https://api.whatsapp.com/send?phone=5583982119090
<https://api.whatsapp.com/send?phone=5583982119090>*

From spoofer-info at caida.org  Sat Aug  8 14:00:11 2020
From: spoofer-info at caida.org (CAIDA Spoofer Project)
Date: Sat, 8 Aug 2020 10:00:11 -0700
Subject: [GTER] =?utf-8?q?Relat=C3=B3rio_Spoofer_para_GTER_-_Jul/2020?=
Message-ID: <1596906011.742492.23926.nullmailer@caida.org>

Em resposta ao feedback de comunidades de seguran?a operacional,
o projeto de valida??o de medidas de endere?o de origem do
CAIDA (https://spoofer.caida.org) est? automaticamente gerando
relat?rios mensais de prefixos BGP originados por ASes os quais
recebemos pacotes com endere?o de origem spoofed (alterado).
Estamos publicando esses relat?rios para garantir que essa
informa??o alcance contatos operacionais nesses ASes.

Esse relat?rio resume testes conduzidos no bra.

Corre??es de configura??es inferidas durante Jul/2020:
Nome do ASN                                           Corrigido em
264353 Catal?o Bandnet Servi?os Mul                 2020-07-02
265425 NEOLINEPB TELECOM                              2020-07-03
264479 Turbozone Internet                             2020-07-05
262627 TURBINET TELECOM LTDA ME                       2020-07-15
53181  K2 Telecom e Multimidia LTDA M                 2020-07-20
262977 ADSNET TELECOM LTDA ME                         2020-07-30

Mais informa??es sobre as corre??es inferidas est?o dispon?veis em:
https://spoofer.caida.org/remedy.php

Problemas de Valida??o de Endere?o de Origem inferidos em Jul/2020:
Nome do ASN                            Primeiro registro  ?ltimo registro
16735  ALGAR TELECOM S/A                  2017-03-01        2020-07-20
266368 MARIA DO SOCORRO DA SILVA DOS      2017-04-29        2020-07-24
18881  TELEF?NICA BRASIL S.A              2017-05-18        2020-07-16
264478 MEGANET TELECOM                    2017-06-06        2020-07-19
7738   Telemar Norte Leste S.A.           2017-07-23        2020-07-11
262485 S.C. RIO TELECOMUNICACOES E IN     2018-05-17        2020-07-25
262468 Natel Telecom Ltda. - ME           2018-08-08        2020-07-15
28210  VM OPENLINK COMUNICA??O MULT       2018-08-21        2020-07-23
262808 Brasilnet Telecomunica??es L     2018-09-30        2020-07-22
262612 Piotr Piwowar                      2018-11-26        2020-07-20
61730  TECHNET-WIFI TELECOM LTDA ME       2018-12-06        2020-07-29
264066 WP Tecnologia LTDA ME              2018-12-26        2020-07-22
10429  TELEF?NICA BRASIL S.A              2019-02-15        2020-07-16
267544 SIGNET TELECOM                     2019-06-17        2020-07-24
28668  Silva & Silveira Provedor de I     2019-06-24        2020-07-21
53181  K2 Telecom e Multimidia LTDA M     2019-06-25        2020-07-20
265241 Data Fibra Telecom                 2019-07-01        2020-07-21
264110 Econect Itapevi Telecomunica?     2019-07-29        2020-07-21
262832 Infotechnet Informatica e Assi     2019-08-02        2020-07-22
267121 ATPlus Telecom                     2019-08-07        2020-07-20
266261 KBPS TELECOM EIRELI - ME           2019-08-19        2020-07-24
53172  Next Telecomunica??es do Bra     2019-09-12        2020-07-06
53222  Seanet Telecom Ltda                2019-09-13        2020-07-24
265466 Golfinho Internet                  2019-09-24        2020-07-30
52532  Speednet Telecomunica??es Lt     2019-09-25        2020-07-09
53169  Tche Turbo Provedor de Interne     2019-10-02        2020-07-17
268638 Conect Turbo Telecom Eireli-Me     2019-10-03        2020-07-28
14282  PERSIS TELECOM                     2019-10-23        2020-07-23
264281 RS Portal Ltda.                    2019-10-24        2020-07-18
266202 CROHMA SOLUCOES LTDA - ME          2019-11-20        2020-07-22
28352  NETSPEED LTDA                      2019-12-09        2020-07-21
262544 Sulcom Inform?tica Ltda           2019-12-09        2020-07-23
61704  Conectiva Fibra                    2019-12-13        2020-07-27
266013 Moratec Equipamentos Ltda.         2019-12-26        2020-07-21
28245  NETDIGIT TELECOMUNICACOES LTDA     2019-12-30        2020-07-21
269517 SPACENET PROVEDOR TELECOM LTDA     2020-01-12        2020-07-13
53054  STETNET INFORMATICA LTDA.          2020-01-15        2020-07-07
267450 oliveira & sousa comunica??e     2020-01-31        2020-07-11
262720 MELO TELECOMUNICACOES LTDA         2020-02-06        2020-07-29
265033 Tecnotec Bibarrense Informatic     2020-02-24        2020-07-24
262627 TURBINET TELECOM LTDA ME           2020-03-07        2020-07-24
269215 Mega Net Telecom Ltda              2020-03-07        2020-07-20
263495 INFOSERVIC INFORMATICA TELECOM     2020-03-16        2020-07-23
264293 Smart Solucoes em Telecomunica     2020-03-31        2020-07-18
262505 N4 Telecomunicacoes LTDA - ME      2020-03-31        2020-07-22
52715  SCORPION TELECOMUNICA??O RIB       2020-04-01        2020-07-23
263959 FLEXTEL NETWORK TELECOMUNICACO     2020-04-08        2020-07-30
267282 roberto da silva pessoa me         2020-04-09        2020-07-16
269457 G+B SISTEMAS E AUTOMACAO LTDA-     2020-04-17        2020-07-24
53045  UAUBR PROVEDOR DE ACESSO A INT     2020-05-01        2020-07-20
263522 ANA ALICE NAZARIO DE OLIVEIRA      2020-05-08        2020-07-18
267091 SANTI & ALMEIDA LTDA - ME          2020-05-13        2020-07-21
264130 GIS TELECOM                        2020-05-15        2020-07-12
265289 MP INFOTELECOM                     2020-05-27        2020-07-20
11921  SECRELNET INFORMATICA LTDA         2020-06-01        2020-07-28
61796  NS Internet Ltda ME                2020-06-02        2020-07-21
263468 Rapnet Comunicacao Multimidia      2020-06-30        2020-07-19
264479 Turbozone Internet                 2020-07-05        2020-07-05
267490 C e B do Amaral Comunicacao -      2020-07-06        2020-07-06
263424 Fonelight Telecomunica??es S     2020-07-06        2020-07-20
265330 Ponto a Ponto Telecom do Brasi     2020-07-07        2020-07-20
263022 CARIRIWEB PROVEDORES DE INTERN     2020-07-09        2020-07-20
263888 FIUZA INFORM?TICA & TELECOMUN      2020-07-10        2020-07-10
267113 CLICKCONNECT SOLUCOES EM INTER     2020-07-10        2020-07-22
267629 SGV TI E TELECOM LTDA              2020-07-12        2020-07-19
61929  RODRIGUES E NECKEL LTDA - ME       2020-07-13        2020-07-23
28329  G8 NETWORKS LTDA                   2020-07-13        2020-07-23
264216 Fenix Wireless Internet Ltda       2020-07-14        2020-07-17
265184 HCNETi TELECOM                     2020-07-20        2020-07-20
264212 IMPACTO TELECOMUNICACOES EIREL     2020-07-26        2020-07-26
263946 HIGH CONNECT REDES DE TELECOMU     2020-07-30        2020-07-30
263661 BRASIL DIGITAL SERVI?OS DE IN      2020-07-31        2020-07-31

Mais informa??es sobre esses testes e de onde recebemos
pacotes alterados est?o dispon?veis em:
https://spoofer.caida.org/recent_tests.php?country_include=bra&no_block=1

Por favor, envie quaisquer sugest?es ou feedback para spoofer-info at caida.org

From fischerdouglas at gmail.com  Tue Aug 11 09:14:39 2020
From: fischerdouglas at gmail.com (Douglas Fischer)
Date: Tue, 11 Aug 2020 09:14:39 -0300
Subject: [GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR
Message-ID: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>

A/C IX.BR

Aaaa?ba! B?o?

C?is acharam que a gente ia esquecer disso n??
HAHAHA!

Para relembrar um pouco,
  para darmos umas risadas,
  e para informar os colegas que n?o sabem do que estamos falando,
  seguem alguns links:

https://youtu.be/Ap3AA2e5jRQ
https://www.flickr.com/photos/nicbr/49352355017/
https://www.flickr.com/photos/nicbr/49351697793/


Bom...
Tenho que dizer que c? de longe estamos vendo movimenta??es que me deixam
feliz!

- Todas novas Localidades j? eram ativadas no modelos novo de
route-servers, com suporte a communities.
- Todas as localidades do IX.BR j? est?o com suporte a BGP communities.

S? pelo suporte as communities, isso j? ? MUITO BOM...
Mas sei que essa mudan?a foi muito mais complicada, pois envolvia mudan?a
no modelo de deploy dos route-servers...
E pelo que sei, juntando com o que eu imagino, melhorias nas pol?ticas de
communities agora podem ser feitas com muito mais agilidade em todas as
localidades.


Mas agora vem as perguntas:

1 - E o Black Hole no IX.BR vai sair?
1.1 - Pelo menos no modo de redistribui??o de rotas para:
1.1.1 - Possibilitar que cada um aplique a a??o de Blackhole na sua
respectiva caixa.
1.1.2 - Redistribuir com um IP de destino da Lan do ATM que resolva para um
MAC DEAD.DEAD.DEAD, possibilitando que isso seja filtrado ACL-L2 na portas
de entrada do fabric das localidade.
(? o ideal? N?O! Mas j? vai ajudar BASTANTE!)
1.2 - Quem sabe, aplicar essa filtragem em ACL-L3.
(Seria o melhor dos mundos, mas depende de capacidade dos devices, e tamb?m
de alt?ssimo n?vel de automa??o.)

2 - E o Jumbo Frame? Vamos come?ar algum teste?
2.1 - Quem sabe liberar 9100+ nas Vlans Bilaterais?
2.2 - Talvez algum teste beta(exclusivamente no L2) do ATMv6 de alguma
localidade menor...




Falando aqui com um dos consumidores do servi?os fornecidos e produtos
providos pelo IX.BR...
 - Oque voc?s precisam de n?s, participantes do IX.BR, para ajudar a fazer
essas coisas acontecerem?
 - ? poss?vel divulgar alguma coisa que j? esteja sendo feita no sentido de
atender essas duas demanda?
 - Existe algum roadmap para alguma atividade relacionada a isso...




-- 
Douglas Fernando Fischer
Eng? de Controle e Automa??o

From job at ntt.net  Tue Aug 11 09:44:02 2020
From: job at ntt.net (Job Snijders)
Date: Tue, 11 Aug 2020 12:44:02 +0000
Subject: [GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR
In-Reply-To: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
References: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
Message-ID: <20200811124402.GH85082@bench.sobornost.net>

Dear group,

On Tue, Aug 11, 2020 at 09:14:39AM -0300, Douglas Fischer wrote:
> Mas agora vem as perguntas:
> 
> 1 - E o Black Hole no IX.BR vai sair?
> 1.1 - Pelo menos no modo de redistribui??o de rotas para:
> 1.1.1 - Possibilitar que cada um aplique a a??o de Blackhole na sua
> respectiva caixa.
> 1.1.2 - Redistribuir com um IP de destino da Lan do ATM que resolva para um
> MAC DEAD.DEAD.DEAD, possibilitando que isso seja filtrado ACL-L2 na portas
> de entrada do fabric das localidade.
> (? o ideal? N?O! Mas j? vai ajudar BASTANTE!)

The above method is not just 'not ideal', but actively dangerous. It
requires all participants to adjust (set 'wide open') their filters,
assume a risk about FIB exhaustion, and require changes on thousands of
devices to be effective.

The method of 'blackholing' by redistributing the to-be-blackholed IP
address as a BGP NLRI to each participant, and asking each participant
to accept the faux next-hop has proven to NOT BE EFFECTIVE.

DE-CIX and other internet exchanges have tried this cheap shortcut and
were never able to prove that the 'feature' actually helped. It turns
out that participants generally are unwilling to make too many
configuration changes, especially if it creates an insecure situation.

The large IXPs tried very hard to produce whitepapers to prove that the
blackholing method is effective, but when you look close at the numbers
you can see that the measured metrics make no sense, and at the scale of
DE-CIX one has to conclude that the feature does not help at all in
dampening the negative effects of DDoS.

Having a route server distribute blackholes to all participants is a
symbolic, ineffective, dangerous facility that I strongly recommend is
not wasted any time on. Don't do it, there are no success stories.

> 1.2 - Quem sabe, aplicar essa filtragem em ACL-L3.
> (Seria o melhor dos mundos, mas depende de capacidade dos devices, e tamb?m
> de alt?ssimo n?vel de automa??o.)

Now, *THIS* is the best method.

Yes, it may require additional engineering and perhaps hardware upgrades,
but hardware is upgraded all the time, and knowing that the community
wants this feature, the IX.BR team can make sure that the next
generation of the platform supports combined L2+L3 ACLs which can be
automatically programmed via some API.

The upside of the combined L2/L3 ACL approach are:

    - 100% safe: participants can only impact their own traffic and not damage other networks

    - 100% no trust required: ACLs only affect the port of the requester of the ACL

    - 100% no changes required on the side of the participant, every
      participant can benefit from this platform feature regardless of
      their router type

    - 100% effective for each port on which the feature becomes available

Before dismissing the L2/L3 ACL solution as 'too expensive', 'too much
work' or 'we need something sooner'. One has to consider whether
deploying an ineffective, dangerous, and useless mechanism really is
worth the effort compared to either not offering blackholing (safe), or
engineering a proper in-fabric IX platform based blackholing solution
which uses L2/L3 ACLs (also safe).

Kind regards,

Job

From rubensk at gmail.com  Tue Aug 11 11:51:23 2020
From: rubensk at gmail.com (Rubens Kuhl)
Date: Tue, 11 Aug 2020 11:51:23 -0300
Subject: [GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR
In-Reply-To: <20200811124402.GH85082@bench.sobornost.net>
References: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
 <20200811124402.GH85082@bench.sobornost.net>
Message-ID: <CAGFn2k1TgnmOGjbZnbHiaS3X_8eD0FQtvvNvV5=fcv0XXSCsVw@mail.gmail.com>

On Tue, Aug 11, 2020 at 9:44 AM Job Snijders <job at ntt.net> wrote:
>
> Dear group,
>
> On Tue, Aug 11, 2020 at 09:14:39AM -0300, Douglas Fischer wrote:
> > Mas agora vem as perguntas:
> >
> > 1 - E o Black Hole no IX.BR vai sair?
> > 1.1 - Pelo menos no modo de redistribui??o de rotas para:
> > 1.1.1 - Possibilitar que cada um aplique a a??o de Blackhole na sua
> > respectiva caixa.
> > 1.1.2 - Redistribuir com um IP de destino da Lan do ATM que resolva para um
> > MAC DEAD.DEAD.DEAD, possibilitando que isso seja filtrado ACL-L2 na portas
> > de entrada do fabric das localidade.
> > (? o ideal? N?O! Mas j? vai ajudar BASTANTE!)
>
> The above method is not just 'not ideal', but actively dangerous. It
> requires all participants to adjust (set 'wide open') their filters,
> assume a risk about FIB exhaustion, and require changes on thousands of
> devices to be effective.
>
> The method of 'blackholing' by redistributing the to-be-blackholed IP
> address as a BGP NLRI to each participant, and asking each participant
> to accept the faux next-hop has proven to NOT BE EFFECTIVE.
>
> DE-CIX and other internet exchanges have tried this cheap shortcut and
> were never able to prove that the 'feature' actually helped. It turns
> out that participants generally are unwilling to make too many
> configuration changes, especially if it creates an insecure situation.


Job,

The L2 solution can be made not to be dependent on member
configuration. The IX can have an ARP responder for the blackholed IP
that answers with a specific MAC address, and the IX matrix can drop
all traffic destined to that MAC address. So if a member null routes
the blackhole IP address, great; the member saves bandwidth in its
connection to the IX. But if not, the ingress filter in the IX drops
it and the traffic doesn't traverse the IX matrix.

The same L2 filter can be suggested to CIX (remote IX accesses) so
this can be done nearest to the traffic source as possible, but also
not depends on whether this is done or not.


Rubens

From emorales at nic.br  Tue Aug 11 11:58:10 2020
From: emorales at nic.br (Eduardo Morales)
Date: Tue, 11 Aug 2020 11:58:10 -0300
Subject: [GTER] =?utf-8?b?W0ludHJhIFJlZGVdIMOJIGFtYW5ow6MsIMOgcyAxMGgg?=
 =?utf-8?q?hor=C3=A1rio_de_Bras=C3=ADlia_=28UTC-3=29=3A_saiba_como_melhora?=
 =?utf-8?q?r_a_efici=C3=AAncia_da_sua_rede_em_live_do_NIC=2Ebr!?=
Message-ID: <9a99b79d-21e3-886a-0771-ff17cbcc7ba8@nic.br>

Ol? Pessoal,


Esperamos por voc?, amanh?(12/08/2020) ?s 10h hor?rio de Bras?lia 
(UTC-3), em mais uma live Intra Rede sempre com assuntos de alto n?vel 
t?cnico e participa??o de renomados especialistas.


Teremos o Daniel Fink (ICANN), a Gabriela Marin (NIC.br), o Henrique de 
Moraes Holschuh (NIC.br), o Rog?rio Malgor (Telef?nica), o Ronaldo Couto 
(PRO ISP) e o Tiago Carrijo Setti (NuiTec) discutindo como provedores 
podem melhorar a efici?ncia da rede, por meio de boas pr?ticas como o 
uso dos DNS Recursivos e Raiz, a import?ncia da medi??o da qualidade da 
Internet, entre outras a??es para garantir uma conex?o de qualidade aos 
seus clientes.

Haver? certifica??o para quem acompanhar a transmiss?o do evento.


Site do evento 
https://intrarede.nic.br/live-qualidade-internet-para-provedores/ .


Acompanhe a transmiss?o amanh?(12/08/2020) ?s 10h hor?rio de Bras?lia 
(UTC-3) em https://www.youtube.com/watch?v=ufx4N0gx0LM ou pela nossa 
p?gina do Facebook (https://www.facebook.com/nic.br). At? j?!


Atenciosamente,

Eduardo Barasal Morales


From job at ntt.net  Tue Aug 11 12:11:19 2020
From: job at ntt.net (Job Snijders)
Date: Tue, 11 Aug 2020 15:11:19 +0000
Subject: [GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR
In-Reply-To: <CAGFn2k1TgnmOGjbZnbHiaS3X_8eD0FQtvvNvV5=fcv0XXSCsVw@mail.gmail.com>
References: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
 <20200811124402.GH85082@bench.sobornost.net>
 <CAGFn2k1TgnmOGjbZnbHiaS3X_8eD0FQtvvNvV5=fcv0XXSCsVw@mail.gmail.com>
Message-ID: <20200811151119.GA23302@bench.sobornost.net>

Dear Rubens,

On Tue, Aug 11, 2020 at 11:51:23AM -0300, Rubens Kuhl wrote:
> The L2 solution can be made not to be dependent on member
> configuration. The IX can have an ARP responder for the blackholed IP
> that answers with a specific MAC address, and the IX matrix can drop
> all traffic destined to that MAC address. So if a member null routes
> the blackhole IP address, great; the member saves bandwidth in its
> connection to the IX. But if not, the ingress filter in the IX drops
> it and the traffic doesn't traverse the IX matrix.

This still requires all participants to accept the blackhole hostroutes
to begin with (open up filters to /32 + /128, disable RPKI), and accept
the discard NEXT_HOP (which is not the same as the BGP speaker) which
has a special MAC address on the platform.

Special configuration that goes against all current BCPs is required
regardless of the ARP responder. Whether an IXP uses an ARP responder
with a special IP address (or not) does not change the fundamental flaws
of the approach.

I repeat my recommendation: please work to invest in an actual solution
that benefits all participants. L3 ACLS (optionally combined with L2)
deployed on the participant ports or somewhere in the IX fabric is a
better solution. An example of a L3-based in-fabric IXP blackholing
solution was deployed at https://unitedix.net/tech/ - this is not new.

Redistribution the blackhole routes via a route server to all route
server participants is a 'marketing' solution, it looks interesting on
paper but is unsafe and ineffective in practise.

Kind regards,

Job

ps. The 'solution' via route servers can easily be replicated via
bilateral direct peering sessions across the fabric. How many people
have actually worked together to allow each other to perform blackholing
inside each others network? Would you feel comfortable getting a BGP
session from a random ASN with potentially random blackhole requests and
blindly automatically honor those requests? I wouldn't. I would not
recommend this to anyone.

From danton.nunes at inexo.com.br  Tue Aug 11 13:12:58 2020
From: danton.nunes at inexo.com.br (Danton Nunes)
Date: Tue, 11 Aug 2020 13:12:58 -0300 (-03)
Subject: [GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR
In-Reply-To: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
References: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2008111311070.6486@zaphod.inexo.com.br>

On Tue, 11 Aug 2020, Douglas Fischer wrote:

> 2 - E o Jumbo Frame? Vamos come?ar algum teste?
> 2.1 - Quem sabe liberar 9100+ nas Vlans Bilaterais?

SIMMM! se n?o no ATM, pelo menos nas bilaterais.

> 2.2 - Talvez algum teste beta(exclusivamente no L2) do ATMv6 de alguma
> localidade menor...

Vou conversar com Marcelo na Nip, pode ser que nos ofere?amos de cobaias 
no IX de S?o Jos? dos Campos.

-- Danton

From fhfrediani at gmail.com  Tue Aug 11 13:46:43 2020
From: fhfrediani at gmail.com (Fernando Frediani)
Date: Tue, 11 Aug 2020 13:46:43 -0300
Subject: [GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR
In-Reply-To: <alpine.DEB.2.21.2008111311070.6486@zaphod.inexo.com.br>
References: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
 <alpine.DEB.2.21.2008111311070.6486@zaphod.inexo.com.br>
Message-ID: <0ebfcf8e-35e1-01a8-ce10-f64031fcd22b@gmail.com>

Embora seja simp?tico ? ideia de suporte ? JumboFrame, creio que ter 
algum suporte ? Blackhole, (seja atrav?s de Route Servers ou em Layer 2 
direto na matriz) seja algo que deva receber mais prioridade por 
beneficiar um n?mero maior de participantes de imediato.

Com rela??o ao JumboFrame ? interessante o que o Danton menciona de 
fazer em IX menores primeiro se houver receio de aplicar direto no 
IX-SP, mesmo que em Bilaterais inicialmente.

Fernando Fediani

On 11/08/2020 13:12, Danton Nunes wrote:
> On Tue, 11 Aug 2020, Douglas Fischer wrote:
>
>> 2 - E o Jumbo Frame? Vamos come?ar algum teste?
>> 2.1 - Quem sabe liberar 9100+ nas Vlans Bilaterais?
>
> SIMMM! se n?o no ATM, pelo menos nas bilaterais.
>
>> 2.2 - Talvez algum teste beta(exclusivamente no L2) do ATMv6 de alguma
>> localidade menor...
>
> Vou conversar com Marcelo na Nip, pode ser que nos ofere?amos de 
> cobaias no IX de S?o Jos? dos Campos.
>
> -- Danton
> -- 
> gter list??? https://eng.registro.br/mailman/listinfo/gter

From fischerdouglas at gmail.com  Tue Aug 11 18:08:52 2020
From: fischerdouglas at gmail.com (Douglas Fischer)
Date: Tue, 11 Aug 2020 18:08:52 -0300
Subject: [GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR
In-Reply-To: <0ebfcf8e-35e1-01a8-ce10-f64031fcd22b@gmail.com>
References: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
 <alpine.DEB.2.21.2008111311070.6486@zaphod.inexo.com.br>
 <0ebfcf8e-35e1-01a8-ce10-f64031fcd22b@gmail.com>
Message-ID: <CAKEr4RSh7_JOVE=TmsjAZY-w_Ktaxzbhmyp5__Cmg7Vm7oLPwA@mail.gmail.com>

Com o suporte a JumboFrame 9100+, e com tecnologias de encapsulamento mais
recentes(pouco overhead, pouco cpu-intesive, e feitas na ASIC), a
necessidade de Vlans Bilaterais quase deixa de existir.


Em ter., 11 de ago. de 2020 ?s 13:47, Fernando Frediani <
fhfrediani at gmail.com> escreveu:

> Embora seja simp?tico ? ideia de suporte ? JumboFrame, creio que ter
> algum suporte ? Blackhole, (seja atrav?s de Route Servers ou em Layer 2
> direto na matriz) seja algo que deva receber mais prioridade por
> beneficiar um n?mero maior de participantes de imediato.
>
> Com rela??o ao JumboFrame ? interessante o que o Danton menciona de
> fazer em IX menores primeiro se houver receio de aplicar direto no
> IX-SP, mesmo que em Bilaterais inicialmente.
>
> Fernando Fediani
>
> On 11/08/2020 13:12, Danton Nunes wrote:
> > On Tue, 11 Aug 2020, Douglas Fischer wrote:
> >
> >> 2 - E o Jumbo Frame? Vamos come?ar algum teste?
> >> 2.1 - Quem sabe liberar 9100+ nas Vlans Bilaterais?
> >
> > SIMMM! se n?o no ATM, pelo menos nas bilaterais.
> >
> >> 2.2 - Talvez algum teste beta(exclusivamente no L2) do ATMv6 de alguma
> >> localidade menor...
> >
> > Vou conversar com Marcelo na Nip, pode ser que nos ofere?amos de
> > cobaias no IX de S?o Jos? dos Campos.
> >
> > -- Danton
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Douglas Fernando Fischer
Eng? de Controle e Automa??o

From rubensk at gmail.com  Tue Aug 11 18:16:49 2020
From: rubensk at gmail.com (Rubens Kuhl)
Date: Tue, 11 Aug 2020 18:16:49 -0300
Subject: [GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR
In-Reply-To: <CAKEr4RSh7_JOVE=TmsjAZY-w_Ktaxzbhmyp5__Cmg7Vm7oLPwA@mail.gmail.com>
References: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
 <alpine.DEB.2.21.2008111311070.6486@zaphod.inexo.com.br>
 <0ebfcf8e-35e1-01a8-ce10-f64031fcd22b@gmail.com>
 <CAKEr4RSh7_JOVE=TmsjAZY-w_Ktaxzbhmyp5__Cmg7Vm7oLPwA@mail.gmail.com>
Message-ID: <CAGFn2k33ggu6VmYRoy=TfDoYp66uccrPHXMnrLGP4CLYe4y1RA@mail.gmail.com>

O maior uso de VLANs bilaterais ? o de contadores para billing de banda.
Quem substitui isso s?o mecanismos de per-MAC-accounting.

Rubens

On Tue, Aug 11, 2020 at 6:09 PM Douglas Fischer
<fischerdouglas at gmail.com> wrote:
>
> Com o suporte a JumboFrame 9100+, e com tecnologias de encapsulamento mais
> recentes(pouco overhead, pouco cpu-intesive, e feitas na ASIC), a
> necessidade de Vlans Bilaterais quase deixa de existir.
>
>
> Em ter., 11 de ago. de 2020 ?s 13:47, Fernando Frediani <
> fhfrediani at gmail.com> escreveu:
>
> > Embora seja simp?tico ? ideia de suporte ? JumboFrame, creio que ter
> > algum suporte ? Blackhole, (seja atrav?s de Route Servers ou em Layer 2
> > direto na matriz) seja algo que deva receber mais prioridade por
> > beneficiar um n?mero maior de participantes de imediato.
> >
> > Com rela??o ao JumboFrame ? interessante o que o Danton menciona de
> > fazer em IX menores primeiro se houver receio de aplicar direto no
> > IX-SP, mesmo que em Bilaterais inicialmente.
> >
> > Fernando Fediani
> >
> > On 11/08/2020 13:12, Danton Nunes wrote:
> > > On Tue, 11 Aug 2020, Douglas Fischer wrote:
> > >
> > >> 2 - E o Jumbo Frame? Vamos come?ar algum teste?
> > >> 2.1 - Quem sabe liberar 9100+ nas Vlans Bilaterais?
> > >
> > > SIMMM! se n?o no ATM, pelo menos nas bilaterais.
> > >
> > >> 2.2 - Talvez algum teste beta(exclusivamente no L2) do ATMv6 de alguma
> > >> localidade menor...
> > >
> > > Vou conversar com Marcelo na Nip, pode ser que nos ofere?amos de
> > > cobaias no IX de S?o Jos? dos Campos.
> > >
> > > -- Danton
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
> --
> Douglas Fernando Fischer
> Eng? de Controle e Automa??o
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

From fischerdouglas at gmail.com  Tue Aug 11 19:40:55 2020
From: fischerdouglas at gmail.com (Douglas Fischer)
Date: Tue, 11 Aug 2020 19:40:55 -0300
Subject: [GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR
In-Reply-To: <CAGFn2k33ggu6VmYRoy=TfDoYp66uccrPHXMnrLGP4CLYe4y1RA@mail.gmail.com>
References: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
 <alpine.DEB.2.21.2008111311070.6486@zaphod.inexo.com.br>
 <0ebfcf8e-35e1-01a8-ce10-f64031fcd22b@gmail.com>
 <CAKEr4RSh7_JOVE=TmsjAZY-w_Ktaxzbhmyp5__Cmg7Vm7oLPwA@mail.gmail.com>
 <CAGFn2k33ggu6VmYRoy=TfDoYp66uccrPHXMnrLGP4CLYe4y1RA@mail.gmail.com>
Message-ID: <CAKEr4RQXkL2aG8Ek-5cDU5d-tyVgoP6mtLt=_Fx=V=sC8oTsWg@mail.gmail.com>

Entendo sua coloca??o, e faz algum sentido...

Mas essa an?lise implica que "tudo que vier daquele MAC vai ser
contabilizado como banda paga".
E isso n?o necessariamente ? verdade.

Existem situa??es em que atrav?s de uma bilateral num IX se pode
transportar algu?m para outro IX.
E outras situa??es que s?o muito pol?micas para serem comentadas.


Em ter., 11 de ago. de 2020 ?s 18:17, Rubens Kuhl <rubensk at gmail.com>
escreveu:

> O maior uso de VLANs bilaterais ? o de contadores para billing de banda.
> Quem substitui isso s?o mecanismos de per-MAC-accounting.
>
> Rubens
>
> On Tue, Aug 11, 2020 at 6:09 PM Douglas Fischer
> <fischerdouglas at gmail.com> wrote:
> >
> > Com o suporte a JumboFrame 9100+, e com tecnologias de encapsulamento
> mais
> > recentes(pouco overhead, pouco cpu-intesive, e feitas na ASIC), a
> > necessidade de Vlans Bilaterais quase deixa de existir.
> >
> >
> > Em ter., 11 de ago. de 2020 ?s 13:47, Fernando Frediani <
> > fhfrediani at gmail.com> escreveu:
> >
> > > Embora seja simp?tico ? ideia de suporte ? JumboFrame, creio que ter
> > > algum suporte ? Blackhole, (seja atrav?s de Route Servers ou em Layer 2
> > > direto na matriz) seja algo que deva receber mais prioridade por
> > > beneficiar um n?mero maior de participantes de imediato.
> > >
> > > Com rela??o ao JumboFrame ? interessante o que o Danton menciona de
> > > fazer em IX menores primeiro se houver receio de aplicar direto no
> > > IX-SP, mesmo que em Bilaterais inicialmente.
> > >
> > > Fernando Fediani
> > >
> > > On 11/08/2020 13:12, Danton Nunes wrote:
> > > > On Tue, 11 Aug 2020, Douglas Fischer wrote:
> > > >
> > > >> 2 - E o Jumbo Frame? Vamos come?ar algum teste?
> > > >> 2.1 - Quem sabe liberar 9100+ nas Vlans Bilaterais?
> > > >
> > > > SIMMM! se n?o no ATM, pelo menos nas bilaterais.
> > > >
> > > >> 2.2 - Talvez algum teste beta(exclusivamente no L2) do ATMv6 de
> alguma
> > > >> localidade menor...
> > > >
> > > > Vou conversar com Marcelo na Nip, pode ser que nos ofere?amos de
> > > > cobaias no IX de S?o Jos? dos Campos.
> > > >
> > > > -- Danton
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Eng? de Controle e Automa??o
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Douglas Fernando Fischer
Eng? de Controle e Automa??o

From fhfrediani at gmail.com  Tue Aug 11 20:04:37 2020
From: fhfrediani at gmail.com (Fernando Frediani)
Date: Tue, 11 Aug 2020 20:04:37 -0300
Subject: [GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR
In-Reply-To: <CAKEr4RQXkL2aG8Ek-5cDU5d-tyVgoP6mtLt=_Fx=V=sC8oTsWg@mail.gmail.com>
References: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
 <alpine.DEB.2.21.2008111311070.6486@zaphod.inexo.com.br>
 <0ebfcf8e-35e1-01a8-ce10-f64031fcd22b@gmail.com>
 <CAKEr4RSh7_JOVE=TmsjAZY-w_Ktaxzbhmyp5__Cmg7Vm7oLPwA@mail.gmail.com>
 <CAGFn2k33ggu6VmYRoy=TfDoYp66uccrPHXMnrLGP4CLYe4y1RA@mail.gmail.com>
 <CAKEr4RQXkL2aG8Ek-5cDU5d-tyVgoP6mtLt=_Fx=V=sC8oTsWg@mail.gmail.com>
Message-ID: <CAEHShq-8MC0XUu-=Nt3e72PL3ASEJG7YxiuGTyk7MPWV4A=_cQ@mail.gmail.com>

Uma frase que eu ouvi a um bom tempo atr?s, sempre fez muito sentido pra
mim e creio que deve ser motivo de aten??o em qualquer IX ?: "IX ? Internet
Exchange, n?o Ethernet Exchage".

Sendo a t?cnica/protocolo que for se continuar funcionando em cima de IP
est? valendo.

Fernando

On Tue, 11 Aug 2020, 19:41 Douglas Fischer, <fischerdouglas at gmail.com>
wrote:

> Entendo sua coloca??o, e faz algum sentido...
>
> Mas essa an?lise implica que "tudo que vier daquele MAC vai ser
> contabilizado como banda paga".
> E isso n?o necessariamente ? verdade.
>
> Existem situa??es em que atrav?s de uma bilateral num IX se pode
> transportar algu?m para outro IX.
> E outras situa??es que s?o muito pol?micas para serem comentadas.
>
>
> Em ter., 11 de ago. de 2020 ?s 18:17, Rubens Kuhl <rubensk at gmail.com>
> escreveu:
>
> > O maior uso de VLANs bilaterais ? o de contadores para billing de banda.
> > Quem substitui isso s?o mecanismos de per-MAC-accounting.
> >
> > Rubens
> >
> > On Tue, Aug 11, 2020 at 6:09 PM Douglas Fischer
> > <fischerdouglas at gmail.com> wrote:
> > >
> > > Com o suporte a JumboFrame 9100+, e com tecnologias de encapsulamento
> > mais
> > > recentes(pouco overhead, pouco cpu-intesive, e feitas na ASIC), a
> > > necessidade de Vlans Bilaterais quase deixa de existir.
> > >
> > >
> > > Em ter., 11 de ago. de 2020 ?s 13:47, Fernando Frediani <
> > > fhfrediani at gmail.com> escreveu:
> > >
> > > > Embora seja simp?tico ? ideia de suporte ? JumboFrame, creio que ter
> > > > algum suporte ? Blackhole, (seja atrav?s de Route Servers ou em
> Layer 2
> > > > direto na matriz) seja algo que deva receber mais prioridade por
> > > > beneficiar um n?mero maior de participantes de imediato.
> > > >
> > > > Com rela??o ao JumboFrame ? interessante o que o Danton menciona de
> > > > fazer em IX menores primeiro se houver receio de aplicar direto no
> > > > IX-SP, mesmo que em Bilaterais inicialmente.
> > > >
> > > > Fernando Fediani
> > > >
> > > > On 11/08/2020 13:12, Danton Nunes wrote:
> > > > > On Tue, 11 Aug 2020, Douglas Fischer wrote:
> > > > >
> > > > >> 2 - E o Jumbo Frame? Vamos come?ar algum teste?
> > > > >> 2.1 - Quem sabe liberar 9100+ nas Vlans Bilaterais?
> > > > >
> > > > > SIMMM! se n?o no ATM, pelo menos nas bilaterais.
> > > > >
> > > > >> 2.2 - Talvez algum teste beta(exclusivamente no L2) do ATMv6 de
> > alguma
> > > > >> localidade menor...
> > > > >
> > > > > Vou conversar com Marcelo na Nip, pode ser que nos ofere?amos de
> > > > > cobaias no IX de S?o Jos? dos Campos.
> > > > >
> > > > > -- Danton
> > > > > --
> > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > >
> > >
> > > --
> > > Douglas Fernando Fischer
> > > Eng? de Controle e Automa??o
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
> --
> Douglas Fernando Fischer
> Eng? de Controle e Automa??o
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From fischerdouglas at gmail.com  Tue Aug 11 22:51:25 2020
From: fischerdouglas at gmail.com (Douglas Fischer)
Date: Tue, 11 Aug 2020 22:51:25 -0300
Subject: [GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR
In-Reply-To: <20200811151119.GA23302@bench.sobornost.net>
References: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
 <20200811124402.GH85082@bench.sobornost.net>
 <CAGFn2k1TgnmOGjbZnbHiaS3X_8eD0FQtvvNvV5=fcv0XXSCsVw@mail.gmail.com>
 <20200811151119.GA23302@bench.sobornost.net>
Message-ID: <CAKEr4RSe_MmYep9wDYrMcSRk-ue66rxL1VgFzurbQCm5_4JPNw@mail.gmail.com>

Hello Job!

I Agree with you on several points that you brought:
 - FIB Exhaustion could kill participant routers
 - No correct treatment to Blackhole Prefixes could generate an even
worst effect than removing announces to IXP.
But I believe that with some extra effort, could be possible to mitigate
those downsides.


I have two lines of arguments for you. So I will Split it...



The 1st is corroborative
------------------------

OK, L3 filtering is the right way to deploy Blackhole on IXPs! But(there is
always a but)
The most feasible way to deploy L3 filtering on Fabric is based on FlowSpec.
And... Switchs with support for FlowSpec are very expensive!

Considering that, on a brainstorm with a friend, we talked about a crazy
idea to deploy Dynamic L3 Filtering on Switchs without Flowspec.

Maybe reinventing the wheel, but in a crude way the idea would be:

 a - ExaBGP as a peer of route-servers, receiving the blackhole prefixes.
     On every change on those prefixes export then to txt.
 b - Aggregate that txt with the prefixes to be blackholed
 c - Convert those aggregated prefixes to a yang access-list format
 d- Ansible(or equivalent) push that yang ACL via netconf/ssh to
the Switchs of IXP.

Off course this is an alpha idea, and must consider a lot of other
limitations:
- ACL-L3 Limits of L2 devices of the fabric.
  What would implicate on:
   - Max Blackhole prefix by participant.
   - Methodology to define what prefixes will not be filtered case the ACL
limit get exceeded.




Em ter., 11 de ago. de 2020 ?s 12:11, Job Snijders <job at ntt.net> escreveu:

> Dear Rubens,
>
> On Tue, Aug 11, 2020 at 11:51:23AM -0300, Rubens Kuhl wrote:
> > The L2 solution can be made not to be dependent on member
> > configuration. The IX can have an ARP responder for the blackholed IP
> > that answers with a specific MAC address, and the IX matrix can drop
> > all traffic destined to that MAC address. So if a member null routes
> > the blackhole IP address, great; the member saves bandwidth in its
> > connection to the IX. But if not, the ingress filter in the IX drops
> > it and the traffic doesn't traverse the IX matrix.
>
> This still requires all participants to accept the blackhole hostroutes
> to begin with (open up filters to /32 + /128, disable RPKI), and accept
> the discard NEXT_HOP (which is not the same as the BGP speaker) which
> has a special MAC address on the platform.
>
> Special configuration that goes against all current BCPs is required
> regardless of the ARP responder. Whether an IXP uses an ARP responder
> with a special IP address (or not) does not change the fundamental flaws
> of the approach.
>
> I repeat my recommendation: please work to invest in an actual solution
> that benefits all participants. L3 ACLS (optionally combined with L2)
> deployed on the participant ports or somewhere in the IX fabric is a
> better solution. An example of a L3-based in-fabric IXP blackholing
> solution was deployed at https://unitedix.net/tech/ - this is not new.
>
> Redistribution the blackhole routes via a route server to all route
> server participants is a 'marketing' solution, it looks interesting on
> paper but is unsafe and ineffective in practise.
>
> Kind regards,
>
> Job
>
> ps. The 'solution' via route servers can easily be replicated via
> bilateral direct peering sessions across the fabric. How many people
> have actually worked together to allow each other to perform blackholing
> inside each others network? Would you feel comfortable getting a BGP
> session from a random ASN with potentially random blackhole requests and
> blindly automatically honor those requests? I wouldn't. I would not
> recommend this to anyone.
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Douglas Fernando Fischer
Eng? de Controle e Automa??o

From fischerdouglas at gmail.com  Tue Aug 11 22:51:37 2020
From: fischerdouglas at gmail.com (Douglas Fischer)
Date: Tue, 11 Aug 2020 22:51:37 -0300
Subject: [GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR
In-Reply-To: <CAKEr4RSe_MmYep9wDYrMcSRk-ue66rxL1VgFzurbQCm5_4JPNw@mail.gmail.com>
References: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
 <20200811124402.GH85082@bench.sobornost.net>
 <CAGFn2k1TgnmOGjbZnbHiaS3X_8eD0FQtvvNvV5=fcv0XXSCsVw@mail.gmail.com>
 <20200811151119.GA23302@bench.sobornost.net>
 <CAKEr4RSe_MmYep9wDYrMcSRk-ue66rxL1VgFzurbQCm5_4JPNw@mail.gmail.com>
Message-ID: <CAKEr4RTJ7G22HhS5U7XF5GjZV-v_ZKDmaRtzoqXX5iviPqBuXg@mail.gmail.com>

The 2nd is counter-argumentative
--------------------------------
You mentioned:
"It requires all participants to adjust (set 'wide open') their filters"
Not Exactly!
It will depend of positive/negative reinforcement.
Let me explain...

Well... In matters of keeping IXP Routing Filter up-to-date, I would say
that exist 3 types of Guys.
1 - The fully-hog guy.
That one that does not filter anything, and accept all the information that
receives...
(those are the c?ncer of internet routing security)

2 - The almost committed but always in hurry guy.
That one that follows the instructions of how to do good filtering, but
does it just at the deploy. And never review anything.
On our matter here, he probably will apply a "refuse" to prefixes longer
than /24 and /48.

3 - The lunatic-dedicated guy that do a day-by-day review on the
routing-filters.
That is the one that probably will apply the policy to blackhole the
prefixes with de defined bgp-community 3 hours after the paper release.

Well...

-> The 3rd guy is not a problem!
On the contrary! He should be laureate.
Beyond adjusting his filters to accept /32 or /128 prefixes with the
blackhole community, he certainly will set next-hop to blackhole still
inside his network.
But even if he would forget to /dev/null the packets locally, it would be
dropped the L2 filter(ARP Responder, ACL-L2 to drop dead.dead.dead, and
bla-bla-bla).

-> The 1st guy is a pig!
And will receive the blackhole routes, accept the next-hop, and the packet
his router send will be dropped by the  ACL-L2 to drop dead.dead.dead.
So, in this case, he is not a problem.

-> The 2nd guy...
Normally he is not the problem. But in this situation he is.
His filter won't accept the /32 /128 prefixes, but will still accept the
/24 or /48 routes.
And because of the packet sent from his network to the ASN that doesn't
want packets to a specific destination will continue flowing.

And all that the 2nd guy needs act as the 1st guy is just a bit
reinforcement.

An to help him, my suggestion is:

A tool that would validate if his routing policies are in compliance with
what is demanded by IXP, and:
1 - Notify him
2 - Make this information public on a central portal.

How would be this Tool?
A synthetic participant that would announce an /24 and a /48, and
randomly announce some /32 and /128 as Blackhole and do some pings to each
participant.
(This has yet to be better thought out.)


Getting the information about being in compliance with this Black Hole
routing policy would solve several problems....
A - That 3rd nerd guy that dedicates beyond the limits and almost never has
his effort recognize, will now be on the green list.
B - The Pig guys will be always on the red list.
C - The 2nd, always in a hurry guy, will receive the incentive to do the
right thing.
D - This kind of information could be used to feed MANRS.

Em ter., 11 de ago. de 2020 ?s 22:51, Douglas Fischer <
fischerdouglas at gmail.com> escreveu:

> Hello Job!
>
> I Agree with you on several points that you brought:
>  - FIB Exhaustion could kill participant routers
>  - No correct treatment to Blackhole Prefixes could generate an even
> worst effect than removing announces to IXP.
> But I believe that with some extra effort, could be possible to mitigate
> those downsides.
>
>
> I have two lines of arguments for you. So I will Split it...
>
>
>
> The 1st is corroborative
> ------------------------
>
> OK, L3 filtering is the right way to deploy Blackhole on IXPs! But(there
> is always a but)
> The most feasible way to deploy L3 filtering on Fabric is based on
> FlowSpec.
> And... Switchs with support for FlowSpec are very expensive!
>
> Considering that, on a brainstorm with a friend, we talked about a crazy
> idea to deploy Dynamic L3 Filtering on Switchs without Flowspec.
>
> Maybe reinventing the wheel, but in a crude way the idea would be:
>
>  a - ExaBGP as a peer of route-servers, receiving the blackhole prefixes.
>      On every change on those prefixes export then to txt.
>  b - Aggregate that txt with the prefixes to be blackholed
>  c - Convert those aggregated prefixes to a yang access-list format
>  d- Ansible(or equivalent) push that yang ACL via netconf/ssh to
> the Switchs of IXP.
>
> Off course this is an alpha idea, and must consider a lot of other
> limitations:
> - ACL-L3 Limits of L2 devices of the fabric.
>   What would implicate on:
>    - Max Blackhole prefix by participant.
>    - Methodology to define what prefixes will not be filtered case the ACL
> limit get exceeded.
>
>
>
>
> Em ter., 11 de ago. de 2020 ?s 12:11, Job Snijders <job at ntt.net> escreveu:
>
>> Dear Rubens,
>>
>> On Tue, Aug 11, 2020 at 11:51:23AM -0300, Rubens Kuhl wrote:
>> > The L2 solution can be made not to be dependent on member
>> > configuration. The IX can have an ARP responder for the blackholed IP
>> > that answers with a specific MAC address, and the IX matrix can drop
>> > all traffic destined to that MAC address. So if a member null routes
>> > the blackhole IP address, great; the member saves bandwidth in its
>> > connection to the IX. But if not, the ingress filter in the IX drops
>> > it and the traffic doesn't traverse the IX matrix.
>>
>> This still requires all participants to accept the blackhole hostroutes
>> to begin with (open up filters to /32 + /128, disable RPKI), and accept
>> the discard NEXT_HOP (which is not the same as the BGP speaker) which
>> has a special MAC address on the platform.
>>
>> Special configuration that goes against all current BCPs is required
>> regardless of the ARP responder. Whether an IXP uses an ARP responder
>> with a special IP address (or not) does not change the fundamental flaws
>> of the approach.
>>
>> I repeat my recommendation: please work to invest in an actual solution
>> that benefits all participants. L3 ACLS (optionally combined with L2)
>> deployed on the participant ports or somewhere in the IX fabric is a
>> better solution. An example of a L3-based in-fabric IXP blackholing
>> solution was deployed at https://unitedix.net/tech/ - this is not new.
>>
>> Redistribution the blackhole routes via a route server to all route
>> server participants is a 'marketing' solution, it looks interesting on
>> paper but is unsafe and ineffective in practise.
>>
>> Kind regards,
>>
>> Job
>>
>> ps. The 'solution' via route servers can easily be replicated via
>> bilateral direct peering sessions across the fabric. How many people
>> have actually worked together to allow each other to perform blackholing
>> inside each others network? Would you feel comfortable getting a BGP
>> session from a random ASN with potentially random blackhole requests and
>> blindly automatically honor those requests? I wouldn't. I would not
>> recommend this to anyone.
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
>
> --
> Douglas Fernando Fischer
> Eng? de Controle e Automa??o
>


-- 
Douglas Fernando Fischer
Eng? de Controle e Automa??o

From job at ntt.net  Wed Aug 12 07:22:50 2020
From: job at ntt.net (Job Snijders)
Date: Wed, 12 Aug 2020 10:22:50 +0000
Subject: [GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR
In-Reply-To: <CAKEr4RSe_MmYep9wDYrMcSRk-ue66rxL1VgFzurbQCm5_4JPNw@mail.gmail.com>
References: <CAKEr4RRbf=xYE0PZ3BurPQ6GDKf9p+2QQoyG2+3wwjx8caH6Sw@mail.gmail.com>
 <20200811124402.GH85082@bench.sobornost.net>
 <CAGFn2k1TgnmOGjbZnbHiaS3X_8eD0FQtvvNvV5=fcv0XXSCsVw@mail.gmail.com>
 <20200811151119.GA23302@bench.sobornost.net>
 <CAKEr4RSe_MmYep9wDYrMcSRk-ue66rxL1VgFzurbQCm5_4JPNw@mail.gmail.com>
Message-ID: <20200812102250.GE57963@bench.sobornost.net>

On Tue, Aug 11, 2020 at 10:51:25PM -0300, Douglas Fischer wrote:
> The 1st is corroborative
> ------------------------
> 
> OK, L3 filtering is the right way to deploy Blackhole on IXPs! But(there is
> always a but)
> The most feasible way to deploy L3 filtering on Fabric is based on FlowSpec.
> And... Switchs with support for FlowSpec are very expensive!
> 
> Considering that, on a brainstorm with a friend, we talked about a crazy
> idea to deploy Dynamic L3 Filtering on Switchs without Flowspec.
> 
> Maybe reinventing the wheel, but in a crude way the idea would be:
> 
>  a - ExaBGP as a peer of route-servers, receiving the blackhole prefixes.
>      On every change on those prefixes export then to txt.
>  b - Aggregate that txt with the prefixes to be blackholed
>  c - Convert those aggregated prefixes to a yang access-list format
>  d- Ansible(or equivalent) push that yang ACL via netconf/ssh to
> the Switchs of IXP.
> 
> Off course this is an alpha idea, and must consider a lot of other
> limitations:
> - ACL-L3 Limits of L2 devices of the fabric.
>   What would implicate on:
>    - Max Blackhole prefix by participant.
>    - Methodology to define what prefixes will not be filtered case the ACL
> limit get exceeded.

The above is the approach taken at United IX and some other places. The
concept is to take BGP and convert it into a deployed combined L2/L3
ACL.

I mention combined L2/L3 ACLs because if the MAC address of the
participant is used for matching, the IX operator can deploy the ACL in
many places inside the fabric, saving bandwidth on ingress->egress from
a platform-wide perspective.

I think you are right that deploying flowspec (from participant to
programming an IX switch) will be very hard, the path you propose makes
more sense.

Kind regards,

Job

From jefferson.gondek at iveloz.net.br  Wed Aug 12 19:28:40 2020
From: jefferson.gondek at iveloz.net.br (Jefferson Gondek)
Date: Wed, 12 Aug 2020 19:28:40 -0300
Subject: [GTER] AS264417 -> Repassando meus AS
Message-ID: <6c1a1988-816b-3dcb-ece6-8327ebd1a82a@iveloz.net.br>

Boa noite pessoal!

Algu?m do grupo tem contato com o pessoal da *MEGALINK Telecom 
AS264417*, o pessoal est? repassando nossos an?ncios sem permiss?o,
sendo que n?o temos transito com eles, e j? pedimos por email e tentamos 
contato por?m sem resposta.

Se algu?m for amigo e puder ajudar agrade?o.

Est? nos causando alguns problemas.


-- 

From felipe.coutinho.videira at gmail.com  Thu Aug 13 10:14:10 2020
From: felipe.coutinho.videira at gmail.com (Felipe Videira)
Date: Thu, 13 Aug 2020 10:14:10 -0300
Subject: [GTER] AS264417 -> Repassando meus AS
In-Reply-To: <6c1a1988-816b-3dcb-ece6-8327ebd1a82a@iveloz.net.br>
References: <6c1a1988-816b-3dcb-ece6-8327ebd1a82a@iveloz.net.br>
Message-ID: <CAChJG6OkjL1Ha0vUtKMnx0OHnJ9Tx284jfXwYo2EpEsvb4nm0Q@mail.gmail.com>

Jefferson, Bom dia.

Se eles est?o propagando seus anuncios indevidamente aprendidos no
IX(infelizmente acontece),
recomendo inicialmente nao trocar trafego com eles no IX, marcando
community no
seu anuncio.

para evitar problemas com  assimetria, tamb?m recomendo rejeitar
temporariamente o ASPATH dele no seu
import no IX. assim voce somente alcan?ar? e ser? alcan?ado por este AS a
partir do seu transito.


os dados do Whois do NIC.br deste AS sao os seguintes:


https://registro.br/tecnologia/ferramentas/whois/?search=AS264417


Atenciosamente,

Felipe Videira
Analista de Redes

Em qua., 12 de ago. de 2020 ?s 20:27, Jefferson Gondek <
jefferson.gondek at iveloz.net.br> escreveu:

> Boa noite pessoal!
>
> Algu?m do grupo tem contato com o pessoal da *MEGALINK Telecom
> AS264417*, o pessoal est? repassando nossos an?ncios sem permiss?o,
> sendo que n?o temos transito com eles, e j? pedimos por email e tentamos
> contato por?m sem resposta.
>
> Se algu?m for amigo e puder ajudar agrade?o.
>
> Est? nos causando alguns problemas.
>
>
> --
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From jefferson at provedorway.com  Thu Aug 13 13:25:50 2020
From: jefferson at provedorway.com (Jefferson)
Date: Thu, 13 Aug 2020 13:25:50 -0300
Subject: [GTER] RES:  AS264417 -> Repassando meus AS
In-Reply-To: <CAChJG6OkjL1Ha0vUtKMnx0OHnJ9Tx284jfXwYo2EpEsvb4nm0Q@mail.gmail.com>
References: <6c1a1988-816b-3dcb-ece6-8327ebd1a82a@iveloz.net.br>
 <CAChJG6OkjL1Ha0vUtKMnx0OHnJ9Tx284jfXwYo2EpEsvb4nm0Q@mail.gmail.com>
Message-ID: <001d01d6718e$68623690$3926a3b0$@provedorway.com>

Obrigado Felipe

-----Mensagem original-----
De: gter <gter-bounces at eng.registro.br> Em nome de Felipe Videira
Enviada em: quinta-feira, 13 de agosto de 2020 10:14
Para: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>
Assunto: Re: [GTER] AS264417 -> Repassando meus AS

Jefferson, Bom dia.

Se eles est?o propagando seus anuncios indevidamente aprendidos no IX(infelizmente acontece), recomendo inicialmente nao trocar trafego com eles no IX, marcando community no seu anuncio.

para evitar problemas com  assimetria, tamb?m recomendo rejeitar temporariamente o ASPATH dele no seu import no IX. assim voce somente alcan?ar? e ser? alcan?ado por este AS a partir do seu transito.


os dados do Whois do NIC.br deste AS sao os seguintes:


https://registro.br/tecnologia/ferramentas/whois/?search=AS264417


Atenciosamente,

Felipe Videira
Analista de Redes

Em qua., 12 de ago. de 2020 ?s 20:27, Jefferson Gondek < jefferson.gondek at iveloz.net.br> escreveu:

> Boa noite pessoal!
>
> Algu?m do grupo tem contato com o pessoal da *MEGALINK Telecom 
> AS264417*, o pessoal est? repassando nossos an?ncios sem permiss?o, 
> sendo que n?o temos transito com eles, e j? pedimos por email e 
> tentamos contato por?m sem resposta.
>
> Se algu?m for amigo e puder ajudar agrade?o.
>
> Est? nos causando alguns problemas.
>
>
> --
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>
--
gter list    https://eng.registro.br/mailman/listinfo/gter


From emorales at nic.br  Thu Aug 13 14:24:10 2020
From: emorales at nic.br (Eduardo Morales)
Date: Thu, 13 Aug 2020 14:24:10 -0300
Subject: [GTER] =?utf-8?q?Novo_epis=C3=B3dio_do_podcast_camada8=3A_Rumo_a?=
 =?utf-8?q?o_IPv6=28Hexa=29_Brasil!?=
Message-ID: <d158502c-d2b7-2cc5-0cc2-395939cc94bf@nic.br>

Ol? Pessoal,


Boa not?cia aos profissionais e apaixonados por tecnologia e 
infraestrutura da Internet! Est? no ar mais um epis?dio do Camada8, 
podcast do Ceptro.br/NIC.br. O assunto da vez ? o IPv6. Se voc? ? 
administrador de redes e ainda n?o entendeu a necessidade de implantar o 
protocolo, n?o perca!


O epis?dio explica ainda os avan?os na ado??o do IPv6 pelo mundo, seus 
desafios e curiosidades.


O conte?do est? no ao ar em: https://nic.br/podcasts/camada8/. Sintonize!


Abs,

Eduardo Barasal Morales


From jefferson.gondek at iveloz.net.br  Thu Aug 13 14:45:15 2020
From: jefferson.gondek at iveloz.net.br (Jefferson Gondek)
Date: Thu, 13 Aug 2020 14:45:15 -0300
Subject: [GTER] RES: AS264417 -> Repassando meus AS
In-Reply-To: <001d01d6718e$68623690$3926a3b0$@provedorway.com>
References: <6c1a1988-816b-3dcb-ece6-8327ebd1a82a@iveloz.net.br>
 <CAChJG6OkjL1Ha0vUtKMnx0OHnJ9Tx284jfXwYo2EpEsvb4nm0Q@mail.gmail.com>
 <001d01d6718e$68623690$3926a3b0$@provedorway.com>
Message-ID: <b0165f3a-311a-22b8-676e-259939c37617@iveloz.net.br>

Boa tarde a todos,

 ? Gostaria de agradecer ae a ajuda de todos.

 ? O respons?vel da Megalink j? me respondeu e estamos tratando o caso.

Abra?os !!!


Em 13/08/2020 13:25, Jefferson escreveu:
> Obrigado Felipe
>
> -----Mensagem original-----
> De: gter <gter-bounces at eng.registro.br> Em nome de Felipe Videira
> Enviada em: quinta-feira, 13 de agosto de 2020 10:14
> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>
> Assunto: Re: [GTER] AS264417 -> Repassando meus AS
>
> Jefferson, Bom dia.
>
> Se eles est?o propagando seus anuncios indevidamente aprendidos no IX(infelizmente acontece), recomendo inicialmente nao trocar trafego com eles no IX, marcando community no seu anuncio.
>
> para evitar problemas com  assimetria, tamb?m recomendo rejeitar temporariamente o ASPATH dele no seu import no IX. assim voce somente alcan?ar? e ser? alcan?ado por este AS a partir do seu transito.
>
>
> os dados do Whois do NIC.br deste AS sao os seguintes:
>
>
> https://registro.br/tecnologia/ferramentas/whois/?search=AS264417
>
>
> Atenciosamente,
>
> Felipe Videira
> Analista de Redes
>
> Em qua., 12 de ago. de 2020 ?s 20:27, Jefferson Gondek < jefferson.gondek at iveloz.net.br> escreveu:
>
>> Boa noite pessoal!
>>
>> Algu?m do grupo tem contato com o pessoal da *MEGALINK Telecom
>> AS264417*, o pessoal est? repassando nossos an?ncios sem permiss?o,
>> sendo que n?o temos transito com eles, e j? pedimos por email e
>> tentamos contato por?m sem resposta.
>>
>> Se algu?m for amigo e puder ajudar agrade?o.
>>
>> Est? nos causando alguns problemas.
>>
>>
>> --
>> --
>> 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
-- 


From lucas.bocchi at gmail.com  Thu Aug 13 19:39:09 2020
From: lucas.bocchi at gmail.com (Lucas Willian Bocchi)
Date: Thu, 13 Aug 2020 19:39:09 -0300
Subject: [GTER] Novas contas no portal PAS.NIC.BR
In-Reply-To: <CAO4k367eUnWFBfJnsreDC=X46sy_KSRGWxthVJ1C3q-9NPfoKQ@mail.gmail.com>
References: <CA+m52=f82U8z-_2XOwvcUKfK0s2JhoZZwEYY=QEb-2ZkAJd3YA@mail.gmail.com>
 <CAO4k367eUnWFBfJnsreDC=X46sy_KSRGWxthVJ1C3q-9NPfoKQ@mail.gmail.com>
Message-ID: <CA+m52=f-apva0=vpObWuwqdS+b7GW8E-6FY4f2YLhJAQFyHt_g@mail.gmail.com>

Pessoal
Com quem posso falar sobre esse problema?
Mandei mensagem para o pessoal do nic e at? agora n?o responderam.
Se algu?m puder ajudar, agrade?o.

Em sex., 24 de jul. de 2020 ?s 14:11, Alexandre Aleixo | Opticalhost <
alexandre at opticalhost.com.br> escreveu:

> Tive o mesmo problema h? algumas semanas...
>
> Tentei outras vezes uns dias depois, novamente sem sucesso.
>
> Alexandre Aleixo
>
>
>
>
> Em sex., 24 de jul. de 2020 ?s 13:16, Lucas Willian Bocchi <
> lucas.bocchi at gmail.com> escreveu:
>
> > Boa tarde Senhores
> > O funcionamento do portal do PAS do nic-br est? ok? Estou tentando criar
> > uma nova conta mas o certificado est? dando como expirado. Al?m disso, os
> > menus est?o apresentando v?rios erros (modificar senha, criar contas,
> etc).
> > J? tentei cadastrar o e-mail e recadastrar v?rias vezes, e, al?m dos
> erros,
> > quando d? certo, n?o est? vindo o e-mail de confirma??o do cadastro.
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From alexandre at opticalhost.com.br  Thu Aug 13 20:28:20 2020
From: alexandre at opticalhost.com.br (Alexandre Aleixo | Opticalhost)
Date: Thu, 13 Aug 2020 20:28:20 -0300
Subject: [GTER] Novas contas no portal PAS.NIC.BR
In-Reply-To: <CA+m52=f-apva0=vpObWuwqdS+b7GW8E-6FY4f2YLhJAQFyHt_g@mail.gmail.com>
References: <CA+m52=f82U8z-_2XOwvcUKfK0s2JhoZZwEYY=QEb-2ZkAJd3YA@mail.gmail.com>
 <CAO4k367eUnWFBfJnsreDC=X46sy_KSRGWxthVJ1C3q-9NPfoKQ@mail.gmail.com>
 <CA+m52=f-apva0=vpObWuwqdS+b7GW8E-6FY4f2YLhJAQFyHt_g@mail.gmail.com>
Message-ID: <CAO4k365QdfoD-OvYC9OJHTHuiqKJ6nCXZDwz_R212YPxrJ4JSg@mail.gmail.com>

Tamb?m gostaria...

Estou tentando usar h? semanas, sem sucesso.

Alexandre Aleixo



Em qui., 13 de ago. de 2020 ?s 19:39, Lucas Willian Bocchi <
lucas.bocchi at gmail.com> escreveu:

> Pessoal
> Com quem posso falar sobre esse problema?
> Mandei mensagem para o pessoal do nic e at? agora n?o responderam.
> Se algu?m puder ajudar, agrade?o.
>
> Em sex., 24 de jul. de 2020 ?s 14:11, Alexandre Aleixo | Opticalhost <
> alexandre at opticalhost.com.br> escreveu:
>
> > Tive o mesmo problema h? algumas semanas...
> >
> > Tentei outras vezes uns dias depois, novamente sem sucesso.
> >
> > Alexandre Aleixo
> >
> >
> >
> >
> > Em sex., 24 de jul. de 2020 ?s 13:16, Lucas Willian Bocchi <
> > lucas.bocchi at gmail.com> escreveu:
> >
> > > Boa tarde Senhores
> > > O funcionamento do portal do PAS do nic-br est? ok? Estou tentando
> criar
> > > uma nova conta mas o certificado est? dando como expirado. Al?m disso,
> os
> > > menus est?o apresentando v?rios erros (modificar senha, criar contas,
> > etc).
> > > J? tentei cadastrar o e-mail e recadastrar v?rias vezes, e, al?m dos
> > erros,
> > > quando d? certo, n?o est? vindo o e-mail de confirma??o do cadastro.
> > > --
> > > 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
>

From rubensk at gmail.com  Thu Aug 13 20:44:08 2020
From: rubensk at gmail.com (Rubens Kuhl)
Date: Thu, 13 Aug 2020 20:44:08 -0300
Subject: [GTER] Novas contas no portal PAS.NIC.BR
In-Reply-To: <CAO4k365QdfoD-OvYC9OJHTHuiqKJ6nCXZDwz_R212YPxrJ4JSg@mail.gmail.com>
References: <CA+m52=f82U8z-_2XOwvcUKfK0s2JhoZZwEYY=QEb-2ZkAJd3YA@mail.gmail.com>
 <CAO4k367eUnWFBfJnsreDC=X46sy_KSRGWxthVJ1C3q-9NPfoKQ@mail.gmail.com>
 <CA+m52=f-apva0=vpObWuwqdS+b7GW8E-6FY4f2YLhJAQFyHt_g@mail.gmail.com>
 <CAO4k365QdfoD-OvYC9OJHTHuiqKJ6nCXZDwz_R212YPxrJ4JSg@mail.gmail.com>
Message-ID: <CAGFn2k1Z74ZpYwaR0RqjsmRU4QPJd4bos1TUVoqR2-AMMCNaWA@mail.gmail.com>

Mas por causa do INOC ou outro recurso ?
Se for INOC: https://inoc.nic.br/pedido/


Rubens

On Thu, Aug 13, 2020 at 8:29 PM Alexandre Aleixo | Opticalhost
<alexandre at opticalhost.com.br> wrote:
>
> Tamb?m gostaria...
>
> Estou tentando usar h? semanas, sem sucesso.
>
> Alexandre Aleixo
>
>
>
> Em qui., 13 de ago. de 2020 ?s 19:39, Lucas Willian Bocchi <
> lucas.bocchi at gmail.com> escreveu:
>
> > Pessoal
> > Com quem posso falar sobre esse problema?
> > Mandei mensagem para o pessoal do nic e at? agora n?o responderam.
> > Se algu?m puder ajudar, agrade?o.
> >
> > Em sex., 24 de jul. de 2020 ?s 14:11, Alexandre Aleixo | Opticalhost <
> > alexandre at opticalhost.com.br> escreveu:
> >
> > > Tive o mesmo problema h? algumas semanas...
> > >
> > > Tentei outras vezes uns dias depois, novamente sem sucesso.
> > >
> > > Alexandre Aleixo
> > >
> > >
> > >
> > >
> > > Em sex., 24 de jul. de 2020 ?s 13:16, Lucas Willian Bocchi <
> > > lucas.bocchi at gmail.com> escreveu:
> > >
> > > > Boa tarde Senhores
> > > > O funcionamento do portal do PAS do nic-br est? ok? Estou tentando
> > criar
> > > > uma nova conta mas o certificado est? dando como expirado. Al?m disso,
> > os
> > > > menus est?o apresentando v?rios erros (modificar senha, criar contas,
> > > etc).
> > > > J? tentei cadastrar o e-mail e recadastrar v?rias vezes, e, al?m dos
> > > erros,
> > > > quando d? certo, n?o est? vindo o e-mail de confirma??o do cadastro.
> > > > --
> > > > 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

From alexandre at opticalhost.com.br  Thu Aug 13 21:04:31 2020
From: alexandre at opticalhost.com.br (Alexandre Aleixo | Opticalhost)
Date: Thu, 13 Aug 2020 21:04:31 -0300
Subject: [GTER] Novas contas no portal PAS.NIC.BR
In-Reply-To: <CAGFn2k1Z74ZpYwaR0RqjsmRU4QPJd4bos1TUVoqR2-AMMCNaWA@mail.gmail.com>
References: <CA+m52=f82U8z-_2XOwvcUKfK0s2JhoZZwEYY=QEb-2ZkAJd3YA@mail.gmail.com>
 <CAO4k367eUnWFBfJnsreDC=X46sy_KSRGWxthVJ1C3q-9NPfoKQ@mail.gmail.com>
 <CA+m52=f-apva0=vpObWuwqdS+b7GW8E-6FY4f2YLhJAQFyHt_g@mail.gmail.com>
 <CAO4k365QdfoD-OvYC9OJHTHuiqKJ6nCXZDwz_R212YPxrJ4JSg@mail.gmail.com>
 <CAGFn2k1Z74ZpYwaR0RqjsmRU4QPJd4bos1TUVoqR2-AMMCNaWA@mail.gmail.com>
Message-ID: <CAO4k3671ce_ZHFgwuphZKRzYffqfFusF=e4ifVE9mtE+-HH=bg@mail.gmail.com>

Obrigado, Rubens.

E o Simet, tem algum link alternativo?

Alexandre Aleixo



Em qui., 13 de ago. de 2020 ?s 20:44, Rubens Kuhl <rubensk at gmail.com>
escreveu:

> Mas por causa do INOC ou outro recurso ?
> Se for INOC: https://inoc.nic.br/pedido/
>
>
> Rubens
>
> On Thu, Aug 13, 2020 at 8:29 PM Alexandre Aleixo | Opticalhost
> <alexandre at opticalhost.com.br> wrote:
> >
> > Tamb?m gostaria...
> >
> > Estou tentando usar h? semanas, sem sucesso.
> >
> > Alexandre Aleixo
> >
> >
> >
> > Em qui., 13 de ago. de 2020 ?s 19:39, Lucas Willian Bocchi <
> > lucas.bocchi at gmail.com> escreveu:
> >
> > > Pessoal
> > > Com quem posso falar sobre esse problema?
> > > Mandei mensagem para o pessoal do nic e at? agora n?o responderam.
> > > Se algu?m puder ajudar, agrade?o.
> > >
> > > Em sex., 24 de jul. de 2020 ?s 14:11, Alexandre Aleixo | Opticalhost <
> > > alexandre at opticalhost.com.br> escreveu:
> > >
> > > > Tive o mesmo problema h? algumas semanas...
> > > >
> > > > Tentei outras vezes uns dias depois, novamente sem sucesso.
> > > >
> > > > Alexandre Aleixo
> > > >
> > > >
> > > >
> > > >
> > > > Em sex., 24 de jul. de 2020 ?s 13:16, Lucas Willian Bocchi <
> > > > lucas.bocchi at gmail.com> escreveu:
> > > >
> > > > > Boa tarde Senhores
> > > > > O funcionamento do portal do PAS do nic-br est? ok? Estou tentando
> > > criar
> > > > > uma nova conta mas o certificado est? dando como expirado. Al?m
> disso,
> > > os
> > > > > menus est?o apresentando v?rios erros (modificar senha, criar
> contas,
> > > > etc).
> > > > > J? tentei cadastrar o e-mail e recadastrar v?rias vezes, e, al?m
> dos
> > > > erros,
> > > > > quando d? certo, n?o est? vindo o e-mail de confirma??o do
> cadastro.
> > > > > --
> > > > > 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
>

From lucas.bocchi at gmail.com  Thu Aug 13 21:15:32 2020
From: lucas.bocchi at gmail.com (Lucas Willian Bocchi)
Date: Thu, 13 Aug 2020 21:15:32 -0300
Subject: [GTER] Novas contas no portal PAS.NIC.BR
In-Reply-To: <CAO4k3671ce_ZHFgwuphZKRzYffqfFusF=e4ifVE9mtE+-HH=bg@mail.gmail.com>
References: <CA+m52=f82U8z-_2XOwvcUKfK0s2JhoZZwEYY=QEb-2ZkAJd3YA@mail.gmail.com>
 <CAO4k367eUnWFBfJnsreDC=X46sy_KSRGWxthVJ1C3q-9NPfoKQ@mail.gmail.com>
 <CA+m52=f-apva0=vpObWuwqdS+b7GW8E-6FY4f2YLhJAQFyHt_g@mail.gmail.com>
 <CAO4k365QdfoD-OvYC9OJHTHuiqKJ6nCXZDwz_R212YPxrJ4JSg@mail.gmail.com>
 <CAGFn2k1Z74ZpYwaR0RqjsmRU4QPJd4bos1TUVoqR2-AMMCNaWA@mail.gmail.com>
 <CAO4k3671ce_ZHFgwuphZKRzYffqfFusF=e4ifVE9mtE+-HH=bg@mail.gmail.com>
Message-ID: <CA+m52=d9o36EExiS1=RcU2UNGpumNY7qwgpTO_v=or6sMZ6Lcg@mail.gmail.com>

Eu ia me referir tamb?m ao simet/inoc.

Em qui, 13 de ago de 2020 21:05, Alexandre Aleixo | Opticalhost <
alexandre at opticalhost.com.br> escreveu:

> Obrigado, Rubens.
>
> E o Simet, tem algum link alternativo?
>
> Alexandre Aleixo
>
>
>
> Em qui., 13 de ago. de 2020 ?s 20:44, Rubens Kuhl <rubensk at gmail.com>
> escreveu:
>
> > Mas por causa do INOC ou outro recurso ?
> > Se for INOC: https://inoc.nic.br/pedido/
> >
> >
> > Rubens
> >
> > On Thu, Aug 13, 2020 at 8:29 PM Alexandre Aleixo | Opticalhost
> > <alexandre at opticalhost.com.br> wrote:
> > >
> > > Tamb?m gostaria...
> > >
> > > Estou tentando usar h? semanas, sem sucesso.
> > >
> > > Alexandre Aleixo
> > >
> > >
> > >
> > > Em qui., 13 de ago. de 2020 ?s 19:39, Lucas Willian Bocchi <
> > > lucas.bocchi at gmail.com> escreveu:
> > >
> > > > Pessoal
> > > > Com quem posso falar sobre esse problema?
> > > > Mandei mensagem para o pessoal do nic e at? agora n?o responderam.
> > > > Se algu?m puder ajudar, agrade?o.
> > > >
> > > > Em sex., 24 de jul. de 2020 ?s 14:11, Alexandre Aleixo | Opticalhost
> <
> > > > alexandre at opticalhost.com.br> escreveu:
> > > >
> > > > > Tive o mesmo problema h? algumas semanas...
> > > > >
> > > > > Tentei outras vezes uns dias depois, novamente sem sucesso.
> > > > >
> > > > > Alexandre Aleixo
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Em sex., 24 de jul. de 2020 ?s 13:16, Lucas Willian Bocchi <
> > > > > lucas.bocchi at gmail.com> escreveu:
> > > > >
> > > > > > Boa tarde Senhores
> > > > > > O funcionamento do portal do PAS do nic-br est? ok? Estou
> tentando
> > > > criar
> > > > > > uma nova conta mas o certificado est? dando como expirado. Al?m
> > disso,
> > > > os
> > > > > > menus est?o apresentando v?rios erros (modificar senha, criar
> > contas,
> > > > > etc).
> > > > > > J? tentei cadastrar o e-mail e recadastrar v?rias vezes, e, al?m
> > dos
> > > > > erros,
> > > > > > quando d? certo, n?o est? vindo o e-mail de confirma??o do
> > cadastro.
> > > > > > --
> > > > > > 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
>

From gucrims at gmail.com  Thu Aug 13 22:19:08 2020
From: gucrims at gmail.com (Gustavo Crims)
Date: Thu, 13 Aug 2020 22:19:08 -0300
Subject: [GTER] RES: RES: Falhas em roteadores tp-link
In-Reply-To: <CA+m52=dJAEvxwg46JDKvKt5WBe3S6G7PDdxk0_oVSsOgyo-VbA@mail.gmail.com>
References: <CA+m52=dJAEvxwg46JDKvKt5WBe3S6G7PDdxk0_oVSsOgyo-VbA@mail.gmail.com>
Message-ID: <3B6EB26C-763F-491B-BDD3-C49DE5FD9E43@gmail.com>

Algu?m sabe de algo mais?

Att
Gustavo
Enviado via iPhone

> Em 15 de jul de 2020, ?(s) 17:56, Lucas Willian Bocchi <lucas.bocchi at gmail.com> escreveu:
> 
> ?Algu?m mais soube de algo pessoal?
> 
> 
>> Em ter., 14 de jul. de 2020 ?s 00:42, Elizandro Pacheco <
>> elizandro at pachecotecnologia.net> escreveu:
>> 
>> Fica sempre essa d?vida, pois ouvi relatos tamb?m de gente que diz ter as
>> portas baixas fechada e mesmo assim ocorreu... Mas nessas horas tudo ?
>> muito obscuro, estou torcendo pro meu aqui infectar pra dar uma olhada mais
>> de perto.
>> 
>> Elizandro Pacheco
>> 
>> -----Mensagem original-----
>> De: gter <gter-bounces at eng.registro.br> Em nome de M?rcio Elias Hahn do
>> Nascimento
>> Enviada em: segunda-feira, 13 de julho de 2020 19:01
>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
>> gter at eng.registro.br>
>> Assunto: Re: [GTER] RES: Falhas em roteadores tp-link
>> 
>> Ent?o Elizandro. Utilizamos massivamente modelos da tp-link, e n?o tivemos
>> relatos ainda. Detalhe, portas de acesso fechadas ao mundo exterior...
>> 
>> Em uma pesquisa r?pida esse final de semana achei muitos AS's vizinhos ao
>> meu com grande parte dos acessos a CPE's expostos, e pior, muitos com
>> credenciais padr?es ou facilmente quebr?veis, ai complica a seguran?a
>> mesmo.
>> 
>> Vale a pena o pessoal rever as regras de acesso a ger?ncia desses
>> equipamentos.
>> 
>> Em 2020-07-13 18:25, Elizandro Pacheco escreveu:
>> 
>>> Eu estou com um C6 propositalmente exposto pra tentar pegar um infectado
>> para uma an?lise melhor.
>>> 
>>> Mas t? demorando hehe
>>> 
>>> Elizandro Pacheco
>>> 
>>> -----Mensagem original-----
>>> De: gter <gter-bounces at eng.registro.br> Em nome de Lucas Willian
>>> Bocchi Enviada em: segunda-feira, 13 de julho de 2020 18:23
>>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes
>>> <gter at eng.registro.br>
>>> Assunto: Re: [GTER] Falhas em roteadores tp-link
>>> 
>>> Pelo que identificamos s?o todos os que possuem aquele recurso cloud da
>> tp-link.
>>> A maioria s?o roteadores que est?o dentro da infra. Os nossos clientes
>> quase todos utilizam uma solu??o de firmware aberta com OpenWRT
>> customizado, ent?o s? conseguimos notar ou nos que trocaram os roteadores
>> fornecidos pelo provedor por outros (n?o temos como negar ao cliente o
>> direito de mudar) e que possuem vers?o cloud. Estes da linha WR-849N s?o os
>> preferidos para jogar esta firmware alterada e notamos que os mais afetados
>> seriam os da linha ARCHER.
>>> 
>>> Em seg., 13 de jul. de 2020 ?s 18:12, Andre Almeida
>>> <andre at bnet.com.br>
>>> escreveu:
>>> 
>>> Isso eu tamb?m queria saber.... qual o tipo do ataque.
>>> 
>>> Em seg., 13 de jul. de 2020 ?s 17:58, Bruno Cabral
>>> <bruno at openline.com.br>
>>> escreveu:
>>> 
>>> Ataque externo motivado por acesso wan sem ger?ncia, ataque externo
>>> mesmo com medidas protetivas de wan, backdoor da nsa ou ataque
>>> interno, estilo javascript?
>>> ________________________________
>>> De: gter <gter-bounces at eng.registro.br> em nome de Carlos Wander <
>>> carlos.wander at gmail.com>
>>> Enviado: segunda-feira, 13 de julho de 2020 17:37
>>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
>>> gter at eng.registro.br>
>>> Assunto: Re: [GTER] Falhas em roteadores tp-link
>>> 
>>> Prezado Lucas,
>>> 
>>> H? muitos coment?rios no grupos de WhatsAPP do "Loucos por Telecom",
>> "UBNT OFICIAL", etc.
>>> 
>>> O pessoal postou exemplos de como o ataque ocorre, coment?rios sobre a
>>> TP-link ainda n?o ter se manifestado e dicas de como recuperar os
>>> equipamentos.
>>> 
>>> H? casos de provedores com mais de 2000 equipamentos afetados.
>>> 
>>> At.te.,
>>> 
>>> C. Wander
>>> 
>>> Em seg., 13 de jul. de 2020 ?s 17:12, Lucas Willian Bocchi <
>>> lucas.bocchi at gmail.com> escreveu:
>>> 
>>> Boa tarde senhores.
>>> 
>>> Estamos enfrentando problemas em alguns clientes com roteadores
>>> tp-link que simplesmente pararam de funcionar ou n?o est?o funcionando
>> direito.
>>> Procuramos por alguma not?cia em sites nacionais sobre o problema mas
>> n?o
>> 
>>>> vimos nada de not?cia sobre esse problema ser uma falha de seguran?a
>>>> ou algum ataque.
>>>> Os senhores tiveram este problema em suas infras? Tem alguma not?cia
>>>> oficial do assunto?
>>>> --
>>>> 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
>> 
>> --
>> Att
>> 
>> M?rcio Elias Hahn do Nascimento
>> 
>> [1]
>> 
>> Links:
>> ------
>> [1] http://www.sulinternet.net
>> --
>> 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

From alexandre at specialist.srv.br  Fri Aug 14 23:55:31 2020
From: alexandre at specialist.srv.br (Alexandre C. Fonceca)
Date: Fri, 14 Aug 2020 23:55:31 -0300
Subject: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
In-Reply-To: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
Message-ID: <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>

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)

From bruno at openline.com.br  Sat Aug 15 12:03:04 2020
From: bruno at openline.com.br (Bruno Cabral)
Date: Sat, 15 Aug 2020 15:03:04 +0000
Subject: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
In-Reply-To: <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>,
 <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
Message-ID: <CP2PR80MB3635BC15F985A64695FD20EFF5410@CP2PR80MB3635.lamprd80.prod.outlook.com>

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

From alexandre at specialist.srv.br  Sat Aug 15 12:06:00 2020
From: alexandre at specialist.srv.br (Alexandre C. Fonceca)
Date: Sat, 15 Aug 2020 12:06:00 -0300
Subject: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
In-Reply-To: <CP2PR80MB3635BC15F985A64695FD20EFF5410@CP2PR80MB3635.lamprd80.prod.outlook.com>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
 <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
 <CP2PR80MB3635BC15F985A64695FD20EFF5410@CP2PR80MB3635.lamprd80.prod.outlook.com>
Message-ID: <acaf3b1b-52b0-9d72-084c-9174929abd12@specialist.srv.br>

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


From andre at bnet.com.br  Sat Aug 15 13:09:28 2020
From: andre at bnet.com.br (Andre Almeida)
Date: Sat, 15 Aug 2020 13:09:28 -0300
Subject: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
In-Reply-To: <acaf3b1b-52b0-9d72-084c-9174929abd12@specialist.srv.br>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
 <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
 <CP2PR80MB3635BC15F985A64695FD20EFF5410@CP2PR80MB3635.lamprd80.prod.outlook.com>
 <acaf3b1b-52b0-9d72-084c-9174929abd12@specialist.srv.br>
Message-ID: <CAKAeHyFFk53pVdfrpQghnP6WGk+_s39fdfJZFn346pdFfR8rxg@mail.gmail.com>

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
>

From fhfrediani at gmail.com  Sat Aug 15 15:46:31 2020
From: fhfrediani at gmail.com (Fernando Frediani)
Date: Sat, 15 Aug 2020 15:46:31 -0300
Subject: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
In-Reply-To: <CAKAeHyFFk53pVdfrpQghnP6WGk+_s39fdfJZFn346pdFfR8rxg@mail.gmail.com>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
 <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
 <CP2PR80MB3635BC15F985A64695FD20EFF5410@CP2PR80MB3635.lamprd80.prod.outlook.com>
 <acaf3b1b-52b0-9d72-084c-9174929abd12@specialist.srv.br>
 <CAKAeHyFFk53pVdfrpQghnP6WGk+_s39fdfJZFn346pdFfR8rxg@mail.gmail.com>
Message-ID: <CAEHShq_-x5jVQPTwrF3_iWE+uqbvTEY_tn0zXCGYz3QYuO_J-Q@mail.gmail.com>

+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
>

From daniel.damito at sagenetworks.com.br  Sat Aug 15 15:53:20 2020
From: daniel.damito at sagenetworks.com.br (Daniel Damito S S D da Silva)
Date: Sat, 15 Aug 2020 15:53:20 -0300
Subject: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
In-Reply-To: <CAEHShq_-x5jVQPTwrF3_iWE+uqbvTEY_tn0zXCGYz3QYuO_J-Q@mail.gmail.com>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
 <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
 <CP2PR80MB3635BC15F985A64695FD20EFF5410@CP2PR80MB3635.lamprd80.prod.outlook.com>
 <acaf3b1b-52b0-9d72-084c-9174929abd12@specialist.srv.br>
 <CAKAeHyFFk53pVdfrpQghnP6WGk+_s39fdfJZFn346pdFfR8rxg@mail.gmail.com>
 <CAEHShq_-x5jVQPTwrF3_iWE+uqbvTEY_tn0zXCGYz3QYuO_J-Q@mail.gmail.com>
Message-ID: <CAKxDn42WAVwajgYos-fLppnSaMEos8SSsFVpvxT310f=cHXymQ@mail.gmail.com>

+2

Eu pensei em abrir essa thread antes e fiquei com medo de causar muita
treta kk

Em s?b, 15 de ago de 2020 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
>

From andre.bolzan at fixfibra.com.br  Sat Aug 15 16:28:51 2020
From: andre.bolzan at fixfibra.com.br (Andre Bolzan)
Date: Sat, 15 Aug 2020 16:28:51 -0300
Subject: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
In-Reply-To: <CAKxDn42WAVwajgYos-fLppnSaMEos8SSsFVpvxT310f=cHXymQ@mail.gmail.com>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
 <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
 <CP2PR80MB3635BC15F985A64695FD20EFF5410@CP2PR80MB3635.lamprd80.prod.outlook.com>
 <acaf3b1b-52b0-9d72-084c-9174929abd12@specialist.srv.br>
 <CAKAeHyFFk53pVdfrpQghnP6WGk+_s39fdfJZFn346pdFfR8rxg@mail.gmail.com>
 <CAEHShq_-x5jVQPTwrF3_iWE+uqbvTEY_tn0zXCGYz3QYuO_J-Q@mail.gmail.com>
 <CAKxDn42WAVwajgYos-fLppnSaMEos8SSsFVpvxT310f=cHXymQ@mail.gmail.com>
Message-ID: <CAF1WzFFC2rG3U0SGmPNfrB8eCcFmtSCumYNykv7T+EjxHONizA@mail.gmail.com>

+3

Eu acho, mas acho... De pura opini?o...

N?o s?o os router servers.. Sao as operadores...

Tem 20 dias que 2 operadores vazaram alguns an?ncio nosso de IP dentro
PTT...

Isso prejudicou nosso acesso a AWS da data

A AWS s?o "mostro" tem BGP as a service... Ent?o acho que v?o controlar
an?ncio por conta pr?pria ....

Tudo opini?o... Concordo que n?o faz sentido nenhum...

Em s?b, 15 de ago de 2020 15:53, Daniel Damito S S D da Silva <
daniel.damito at sagenetworks.com.br> escreveu:

> +2
>
> Eu pensei em abrir essa thread antes e fiquei com medo de causar muita
> treta kk
>
> Em s?b, 15 de ago de 2020 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
>

From lucas.bocchi at gmail.com  Sat Aug 15 16:47:02 2020
From: lucas.bocchi at gmail.com (Lucas Willian Bocchi)
Date: Sat, 15 Aug 2020 16:47:02 -0300
Subject: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
In-Reply-To: <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
 <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
Message-ID: <CA+m52=cHdzTp-dUfzQHGnDgX4mV+431f3Om7OGVzKe8L=r2kUw@mail.gmail.com>

Anunciar determinadas coisas diretamente SEM precisar passar pelo
route-server.
Conhe?o muita gente que faz isso pra "prender" cliente, falando que a
lat?ncia deles pra jogos e outros ? melhor por que tem sess?o direta, etc.
Conversa de vendedor.

Em s?b., 15 de ago. de 2020 ?s 11:42, Alexandre C. Fonceca <
alexandre at specialist.srv.br> escreveu:

> 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
>

From rodrigopa.uepb at gmail.com  Sat Aug 15 16:02:52 2020
From: rodrigopa.uepb at gmail.com (Rodrigo Pedrosa de Aguiar)
Date: Sat, 15 Aug 2020 16:02:52 -0300
Subject: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
In-Reply-To: <CAEHShq_-x5jVQPTwrF3_iWE+uqbvTEY_tn0zXCGYz3QYuO_J-Q@mail.gmail.com>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
 <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
 <CP2PR80MB3635BC15F985A64695FD20EFF5410@CP2PR80MB3635.lamprd80.prod.outlook.com>
 <acaf3b1b-52b0-9d72-084c-9174929abd12@specialist.srv.br>
 <CAKAeHyFFk53pVdfrpQghnP6WGk+_s39fdfJZFn346pdFfR8rxg@mail.gmail.com>
 <CAEHShq_-x5jVQPTwrF3_iWE+uqbvTEY_tn0zXCGYz3QYuO_J-Q@mail.gmail.com>
Message-ID: <CAPo9HYea7iC1sUrYc2-2MX=HoOvap7oWN_aOyNgcV=tC=R9czg@mail.gmail.com>

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
>

From andre at bnet.com.br  Sun Aug 16 00:26:27 2020
From: andre at bnet.com.br (Andre Almeida)
Date: Sun, 16 Aug 2020 00:26:27 -0300
Subject: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
In-Reply-To: <CAPo9HYea7iC1sUrYc2-2MX=HoOvap7oWN_aOyNgcV=tC=R9czg@mail.gmail.com>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
 <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
 <CP2PR80MB3635BC15F985A64695FD20EFF5410@CP2PR80MB3635.lamprd80.prod.outlook.com>
 <acaf3b1b-52b0-9d72-084c-9174929abd12@specialist.srv.br>
 <CAKAeHyFFk53pVdfrpQghnP6WGk+_s39fdfJZFn346pdFfR8rxg@mail.gmail.com>
 <CAEHShq_-x5jVQPTwrF3_iWE+uqbvTEY_tn0zXCGYz3QYuO_J-Q@mail.gmail.com>
 <CAPo9HYea7iC1sUrYc2-2MX=HoOvap7oWN_aOyNgcV=tC=R9czg@mail.gmail.com>
Message-ID: <CAKAeHyG=HeppPbA3jFKY9SYPnFWK949uV2FY0T2XwJwqrfGjag@mail.gmail.com>

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
>

From rubensk at gmail.com  Sun Aug 16 09:50:41 2020
From: rubensk at gmail.com (Rubens Kuhl)
Date: Sun, 16 Aug 2020 09:50:41 -0300
Subject: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
In-Reply-To: <CAKAeHyG=HeppPbA3jFKY9SYPnFWK949uV2FY0T2XwJwqrfGjag@mail.gmail.com>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
 <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
 <CP2PR80MB3635BC15F985A64695FD20EFF5410@CP2PR80MB3635.lamprd80.prod.outlook.com>
 <acaf3b1b-52b0-9d72-084c-9174929abd12@specialist.srv.br>
 <CAKAeHyFFk53pVdfrpQghnP6WGk+_s39fdfJZFn346pdFfR8rxg@mail.gmail.com>
 <CAEHShq_-x5jVQPTwrF3_iWE+uqbvTEY_tn0zXCGYz3QYuO_J-Q@mail.gmail.com>
 <CAPo9HYea7iC1sUrYc2-2MX=HoOvap7oWN_aOyNgcV=tC=R9czg@mail.gmail.com>
 <CAKAeHyG=HeppPbA3jFKY9SYPnFWK949uV2FY0T2XwJwqrfGjag@mail.gmail.com>
Message-ID: <CAGFn2k2CgwARNoA=ki71khJzf07dTqrUm7Ad8sEYrTdC_MF4AA@mail.gmail.com>

> 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.

O sponge n?o resolve esse tipo de problema. Ele atua quando o
participante perde conex?o e ainda h? tr?fego buscando aquele destino;
a a??o do sponge ? matar de vez o tr?fego com destino a esse participante.


Rubens

From bruno_william5 at hotmail.com  Sun Aug 16 11:31:26 2020
From: bruno_william5 at hotmail.com (William Santos)
Date: Sun, 16 Aug 2020 14:31:26 +0000
Subject: [GTER] Perda pacotes Globo.com
Message-ID: <DM6PR05MB5500E4406B7070351D985AFBBA5E0@DM6PR05MB5500.namprd05.prod.outlook.com>

Bom dia!

Mais algu?m enfrentando perda de pacotes para globo.com (45.6.52.199 (as28604.riodejaneiro.rj.ix.br<https://bgp.he.net/dns/as28604.riodejaneiro.rj.ix.br>))? Desde ontem (15/08/2020), por volta das 20:35, estamos monitorando perda elevada, na casa dos 50%.

From andre at bnet.com.br  Sun Aug 16 16:52:32 2020
From: andre at bnet.com.br (Andre Almeida)
Date: Sun, 16 Aug 2020 16:52:32 -0300
Subject: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
In-Reply-To: <CAGFn2k2CgwARNoA=ki71khJzf07dTqrUm7Ad8sEYrTdC_MF4AA@mail.gmail.com>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
 <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
 <CP2PR80MB3635BC15F985A64695FD20EFF5410@CP2PR80MB3635.lamprd80.prod.outlook.com>
 <acaf3b1b-52b0-9d72-084c-9174929abd12@specialist.srv.br>
 <CAKAeHyFFk53pVdfrpQghnP6WGk+_s39fdfJZFn346pdFfR8rxg@mail.gmail.com>
 <CAEHShq_-x5jVQPTwrF3_iWE+uqbvTEY_tn0zXCGYz3QYuO_J-Q@mail.gmail.com>
 <CAPo9HYea7iC1sUrYc2-2MX=HoOvap7oWN_aOyNgcV=tC=R9czg@mail.gmail.com>
 <CAKAeHyG=HeppPbA3jFKY9SYPnFWK949uV2FY0T2XwJwqrfGjag@mail.gmail.com>
 <CAGFn2k2CgwARNoA=ki71khJzf07dTqrUm7Ad8sEYrTdC_MF4AA@mail.gmail.com>
Message-ID: <CAKAeHyEnOBzcWPzaKfuR8CGY=yub0foNpcv4o5dKKX0HRqQ_8w@mail.gmail.com>

pode n?o ser a solu??o definitiva, mas vai diminuir bastante o tr?fego de
arp broadcast que rola no ATM. Talvez isso melhore e solucione esses arps
que n?o resolvem nem a pau.

Em dom, 16 de ago de 2020 09:51, Rubens Kuhl <rubensk at gmail.com> escreveu:

> > 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.
>
> O sponge n?o resolve esse tipo de problema. Ele atua quando o
> participante perde conex?o e ainda h? tr?fego buscando aquele destino;
> a a??o do sponge ? matar de vez o tr?fego com destino a esse participante.
>
>
> Rubens
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From rubensk at gmail.com  Sun Aug 16 17:04:05 2020
From: rubensk at gmail.com (Rubens Kuhl)
Date: Sun, 16 Aug 2020 17:04:05 -0300
Subject: [GTER] Fwd: [IX.br] [Info] Peering Amazon / AWS - AS16509
In-Reply-To: <CAKAeHyEnOBzcWPzaKfuR8CGY=yub0foNpcv4o5dKKX0HRqQ_8w@mail.gmail.com>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
 <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
 <CP2PR80MB3635BC15F985A64695FD20EFF5410@CP2PR80MB3635.lamprd80.prod.outlook.com>
 <acaf3b1b-52b0-9d72-084c-9174929abd12@specialist.srv.br>
 <CAKAeHyFFk53pVdfrpQghnP6WGk+_s39fdfJZFn346pdFfR8rxg@mail.gmail.com>
 <CAEHShq_-x5jVQPTwrF3_iWE+uqbvTEY_tn0zXCGYz3QYuO_J-Q@mail.gmail.com>
 <CAPo9HYea7iC1sUrYc2-2MX=HoOvap7oWN_aOyNgcV=tC=R9czg@mail.gmail.com>
 <CAKAeHyG=HeppPbA3jFKY9SYPnFWK949uV2FY0T2XwJwqrfGjag@mail.gmail.com>
 <CAGFn2k2CgwARNoA=ki71khJzf07dTqrUm7Ad8sEYrTdC_MF4AA@mail.gmail.com>
 <CAKAeHyEnOBzcWPzaKfuR8CGY=yub0foNpcv4o5dKKX0HRqQ_8w@mail.gmail.com>
Message-ID: <CAGFn2k14uYkfL8A6qqevtD6iR2rb_c5GDR59Pb7J4Pnpv7ovcw@mail.gmail.com>

On Sun, Aug 16, 2020 at 4:53 PM Andre Almeida <andre at bnet.com.br> wrote:
>
> pode n?o ser a solu??o definitiva, mas vai diminuir bastante o tr?fego de
> arp broadcast que rola no ATM. Talvez isso melhore e solucione esses arps
> que n?o resolvem nem a pau.


N?o ? nem solu??o definitiva nem tempor?ria, apenas um amplificador
adicional de instabilidades.


Rubens

From paivgabriel at gmail.com  Mon Aug 17 11:16:10 2020
From: paivgabriel at gmail.com (Gabriel Wolp)
Date: Mon, 17 Aug 2020 11:16:10 -0300
Subject: [GTER] Rota presa AS3356 Level3
Message-ID: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>

N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da manh?,
porem este ASN ainda mantem o /21 na sua tabela de roteamento e espalhando
este bloco indevidamente, mesmo n?o estando sendo anunciado para nenhum de
nossos upstreams. J? aconteceu isso com algu?m?

From flavio.hayashi at phoenixtelecom.com.br  Mon Aug 17 11:30:14 2020
From: flavio.hayashi at phoenixtelecom.com.br (flavio.hayashi)
Date: Mon, 17 Aug 2020 11:30:14 -0300
Subject: [GTER] Rota presa AS3356 Level3
In-Reply-To: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
Message-ID: <20200817143022.C7595162A6B@eng.registro.br>


Com a Level3 j? aconteceu. S? resolveu com chamado l??Enviado do meu smartphone Samsung Galaxy.
-------- Mensagem original --------De : Gabriel Wolp <paivgabriel at gmail.com> Data: 17/08/2020  11:17  (GMT-03:00) Para: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br> Assunto: [GTER] Rota presa AS3356 Level3 N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da manh?,porem este ASN ainda mantem o /21 na sua tabela de roteamento e espalhandoeste bloco indevidamente, mesmo n?o estando sendo anunciado para nenhum denossos upstreams. J? aconteceu isso com algu?m?--gter list??? https://eng.registro.br/mailman/listinfo/gter

From harrisonconde1 at gmail.com  Mon Aug 17 11:24:46 2020
From: harrisonconde1 at gmail.com (Elpidio Harrison Conde Ananias)
Date: Mon, 17 Aug 2020 11:24:46 -0300
Subject: [GTER] Rota presa AS3356 Level3
In-Reply-To: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
Message-ID: <CAE9KLfXZn_yDvHcQiH+=BFt4t3fx+A==aHr7StDidPn4ZWcqeg@mail.gmail.com>

Bom dia.
Prezado, j? aconteceu isso conosco em Brasilia - DF  com a Level usando o
mesmo ASN como upstream.
A gente parava de anunciar e eles continuavam com o prefixo preso. Foi
resolvido depois de v?rias confer?ncias e chegaram na conclus?o que era
algum equipamento deles desatualizado que estava causando isso.

Em seg., 17 de ago. de 2020 ?s 11:17, Gabriel Wolp <paivgabriel at gmail.com>
escreveu:

> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da manh?,
> porem este ASN ainda mantem o /21 na sua tabela de roteamento e espalhando
> este bloco indevidamente, mesmo n?o estando sendo anunciado para nenhum de
> nossos upstreams. J? aconteceu isso com algu?m?
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From vagnerss2011 at gmail.com  Mon Aug 17 11:27:23 2020
From: vagnerss2011 at gmail.com (vagner silva sousa)
Date: Mon, 17 Aug 2020 11:27:23 -0300
Subject: [GTER] Rota presa AS3356 Level3
In-Reply-To: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
Message-ID: <CAMJy3Ywv-FzAaJAyW1gFTz1VfwC8N4WfAr3pejNisKPXwzGB=A@mail.gmail.com>

Aconteceu comigo 2x essa semana prefixo fica preso com eles e s? volta
quando jogo por outra operadora com o mesmo tamanho.

Em seg., 17 de ago. de 2020 ?s 11:17, Gabriel Wolp <paivgabriel at gmail.com>
escreveu:

> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da manh?,
> porem este ASN ainda mantem o /21 na sua tabela de roteamento e espalhando
> este bloco indevidamente, mesmo n?o estando sendo anunciado para nenhum de
> nossos upstreams. J? aconteceu isso com algu?m?
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From charles at zoominternet.com.br  Mon Aug 17 11:30:35 2020
From: charles at zoominternet.com.br (Charles Barreto Macedo)
Date: Mon, 17 Aug 2020 11:30:35 -0300
Subject: [GTER] Rota presa AS3356 Level3
In-Reply-To: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
Message-ID: <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>

Bom Dia,

Para n?s, ? um problema antigo...  J? aconteceu de demorar mais de 6 Horas
para baixar os an?ncios..

Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <paivgabriel at gmail.com>
escreveu:

> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da manh?,
> porem este ASN ainda mantem o /21 na sua tabela de roteamento e espalhando
> este bloco indevidamente, mesmo n?o estando sendo anunciado para nenhum de
> nossos upstreams. J? aconteceu isso com algu?m?
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Atenciosamente,

Charles Barreto
Zoom Telecomunica??es
(44) 31112-2477

www.zoominternet.com.br

From alexandre at opticalhost.com.br  Mon Aug 17 12:01:08 2020
From: alexandre at opticalhost.com.br (Alexandre Aleixo | Opticalhost)
Date: Mon, 17 Aug 2020 12:01:08 -0300
Subject: [GTER] Rota presa AS3356 Level3
In-Reply-To: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
Message-ID: <CAO4k3643+ZBEgRdS2TiF03+vnOhVfwhTWWk6-CXHwAyKyphDbw@mail.gmail.com>

Tenho visto algo semelhante acontecer com um tr?nsito internacional, mais
especificamente um dos upstreams da Algar (n?o cheguei a anotar qual
especificamente).

Um /23 ? anunciado pra Algar e o /22 desse mesmo bloco ? anunciado por
outra operadora.

Quando a Algar cai, o /23 deveria sumir, dando lugar ao /22, mas persiste
anunciado pelo tr?nsito internacional por cerca de 6 horas, mantendo a
prefer?ncia pelo bloco mais espec?fico, embora esteja fora do ar.

Nesse caso, suspeito que seja algo relacionado ao "hold time" do an?ncio,
que talvez esteja sendo sobrescrito por configs de "hold time"
personalizadas dos tr?nsitos seguintes.

Mas, no seu caso, como a parada n?o foi abrupta, e sim voc? mesmo parou o
an?ncio, o update interrompendo o an?ncio deveria ter chegado nos
tr?nsitos...

Alexandre Aleixo




Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <paivgabriel at gmail.com>
escreveu:

> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da manh?,
> porem este ASN ainda mantem o /21 na sua tabela de roteamento e espalhando
> este bloco indevidamente, mesmo n?o estando sendo anunciado para nenhum de
> nossos upstreams. J? aconteceu isso com algu?m?
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From talesrodarte at gmail.com  Mon Aug 17 12:09:27 2020
From: talesrodarte at gmail.com (Tales Rodarte)
Date: Mon, 17 Aug 2020 12:09:27 -0300
Subject: [GTER] Rota presa AS3356 Level3
In-Reply-To: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
Message-ID: <b0573169-11a2-05ab-0737-909268d09f92@gmail.com>

Toda semana algum cliente com sess?o direta ou indireta pela L3/Century 
relata este problema.
Estou quase padronizando os an?ncios por eles usando sempre prepend.? 
Caso aconte?a pelo menos consigo contornar em partes anunciando sem 
prepend.

Adiantar chamado muitas vezes nem adianta. O tempo deles responderem ? o 
tempo do update propagar e o prefixo parar de ser propagado.

--

Tales Rodarte

Em 17/08/2020 11:16, Gabriel Wolp escreveu:
> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da manh?,
> porem este ASN ainda mantem o /21 na sua tabela de roteamento e espalhando
> este bloco indevidamente, mesmo n?o estando sendo anunciado para nenhum de
> nossos upstreams. J? aconteceu isso com algu?m?
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter



From robson at netnew.com.br  Mon Aug 17 12:13:08 2020
From: robson at netnew.com.br (Robson F. Ramaldes)
Date: Mon, 17 Aug 2020 12:13:08 -0300
Subject: [GTER] RES:  Rota presa AS3356 Level3
In-Reply-To: <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
Message-ID: <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>

Boa tarde

Peguei 2 casos em lugares diferentes com o mesmo problema

Em um, retiramos os an?ncios da sess?o com eles e o 
outro caso foi um rompimento que derrubou a sess?o

ambos as rotas ficaram "presas" nas consultas pelos looking glass 
s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico por outra operadora



Att.

Robson F. Ramaldes


-----Mensagem original-----
De: gter <gter-bounces at eng.registro.br> Em nome de Charles Barreto Macedo
Enviada em: segunda-feira, 17 de agosto de 2020 11:31
Para: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>
Assunto: Re: [GTER] Rota presa AS3356 Level3

Bom Dia,

Para n?s, ? um problema antigo...  J? aconteceu de demorar mais de 6 Horas para baixar os an?ncios..

Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <paivgabriel at gmail.com>
escreveu:

> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da 
> manh?, porem este ASN ainda mantem o /21 na sua tabela de roteamento e 
> espalhando este bloco indevidamente, mesmo n?o estando sendo anunciado 
> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


--
Atenciosamente,

Charles Barreto
Zoom Telecomunica??es
(44) 31112-2477

www.zoominternet.com.br
--
gter list    https://eng.registro.br/mailman/listinfo/gter


From lucas.bocchi at gmail.com  Mon Aug 17 14:16:47 2020
From: lucas.bocchi at gmail.com (Lucas Willian Bocchi)
Date: Mon, 17 Aug 2020 14:16:47 -0300
Subject: [GTER] RES: Rota presa AS3356 Level3
In-Reply-To: <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
Message-ID: <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>

Eu ja reclamei com o time de engenharia deles e nao tive retorno. Tenho
esse problema a meses.
Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.

Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <robson at netnew.com.br>
escreveu:

> Boa tarde
>
> Peguei 2 casos em lugares diferentes com o mesmo problema
>
> Em um, retiramos os an?ncios da sess?o com eles e o
> outro caso foi um rompimento que derrubou a sess?o
>
> ambos as rotas ficaram "presas" nas consultas pelos looking glass
> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico por outra
> operadora
>
>
>
> Att.
>
> Robson F. Ramaldes
>
>
> -----Mensagem original-----
> De: gter <gter-bounces at eng.registro.br> Em nome de Charles Barreto Macedo
> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> gter at eng.registro.br>
> Assunto: Re: [GTER] Rota presa AS3356 Level3
>
> Bom Dia,
>
> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais de 6 Horas
> para baixar os an?ncios..
>
> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <paivgabriel at gmail.com>
> escreveu:
>
> > N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da
> > manh?, porem este ASN ainda mantem o /21 na sua tabela de roteamento e
> > espalhando este bloco indevidamente, mesmo n?o estando sendo anunciado
> > para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
> --
> Atenciosamente,
>
> Charles Barreto
> Zoom Telecomunica??es
> (44) 31112-2477
>
> www.zoominternet.com.br
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From listas at juniormoraes.net.br  Mon Aug 17 15:18:30 2020
From: listas at juniormoraes.net.br (=?UTF-8?Q?J=c3=banior_Moraes?=)
Date: Mon, 17 Aug 2020 15:18:30 -0300
Subject: [GTER] RES: Rota presa AS3356 Level3
In-Reply-To: <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
Message-ID: <41c091d3-36d2-e2c4-79dd-685156c752d8@juniormoraes.net.br>

+1

Tenho problemas semanalmente com eles tamb?m, at? hoje ningu?m retornou 
nada...

Como o colega falou mais abaixo, at? eles reponderem, o prefixo "j?" sumiu.

"j?" = 6hs heheheh

J?nior

Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
> Eu ja reclamei com o time de engenharia deles e nao tive retorno. Tenho
> esse problema a meses.
> Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
>
> Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <robson at netnew.com.br>
> escreveu:
>
>> Boa tarde
>>
>> Peguei 2 casos em lugares diferentes com o mesmo problema
>>
>> Em um, retiramos os an?ncios da sess?o com eles e o
>> outro caso foi um rompimento que derrubou a sess?o
>>
>> ambos as rotas ficaram "presas" nas consultas pelos looking glass
>> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico por outra
>> operadora
>>
>>
>>
>> Att.
>>
>> Robson F. Ramaldes
>>
>>
>> -----Mensagem original-----
>> De: gter <gter-bounces at eng.registro.br> Em nome de Charles Barreto Macedo
>> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
>> gter at eng.registro.br>
>> Assunto: Re: [GTER] Rota presa AS3356 Level3
>>
>> Bom Dia,
>>
>> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais de 6 Horas
>> para baixar os an?ncios..
>>
>> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <paivgabriel at gmail.com>
>> escreveu:
>>
>>> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da
>>> manh?, porem este ASN ainda mantem o /21 na sua tabela de roteamento e
>>> espalhando este bloco indevidamente, mesmo n?o estando sendo anunciado
>>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>
>> --
>> Atenciosamente,
>>
>> Charles Barreto
>> Zoom Telecomunica??es
>> (44) 31112-2477
>>
>> www.zoominternet.com.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

From tiago at radaction.com.br  Mon Aug 17 15:54:47 2020
From: tiago at radaction.com.br (Tiago Arnold)
Date: Mon, 17 Aug 2020 15:54:47 -0300
Subject: [GTER] RES: RES: Falhas em roteadores tp-link
In-Reply-To: <3B6EB26C-763F-491B-BDD3-C49DE5FD9E43@gmail.com>
References: <CA+m52=dJAEvxwg46JDKvKt5WBe3S6G7PDdxk0_oVSsOgyo-VbA@mail.gmail.com>
 <3B6EB26C-763F-491B-BDD3-C49DE5FD9E43@gmail.com>
Message-ID: <CAG4nFnmy-mWKrbzve-wUxG9h-CjQcSPJyfno5N9G5AH48046rQ@mail.gmail.com>

Os relatos que tenho dos tp-link s?o de o wifi para aleatoriamente.

Em sex., 14 de ago. de 2020 ?s 00:13, Gustavo Crims <gucrims at gmail.com>
escreveu:

> Algu?m sabe de algo mais?
>
> Att
> Gustavo
> Enviado via iPhone
>
> > Em 15 de jul de 2020, ?(s) 17:56, Lucas Willian Bocchi <
> lucas.bocchi at gmail.com> escreveu:
> >
> > ?Algu?m mais soube de algo pessoal?
> >
> >
> >> Em ter., 14 de jul. de 2020 ?s 00:42, Elizandro Pacheco <
> >> elizandro at pachecotecnologia.net> escreveu:
> >>
> >> Fica sempre essa d?vida, pois ouvi relatos tamb?m de gente que diz ter
> as
> >> portas baixas fechada e mesmo assim ocorreu... Mas nessas horas tudo ?
> >> muito obscuro, estou torcendo pro meu aqui infectar pra dar uma olhada
> mais
> >> de perto.
> >>
> >> Elizandro Pacheco
> >>
> >> -----Mensagem original-----
> >> De: gter <gter-bounces at eng.registro.br> Em nome de M?rcio Elias Hahn do
> >> Nascimento
> >> Enviada em: segunda-feira, 13 de julho de 2020 19:01
> >> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> >> gter at eng.registro.br>
> >> Assunto: Re: [GTER] RES: Falhas em roteadores tp-link
> >>
> >> Ent?o Elizandro. Utilizamos massivamente modelos da tp-link, e n?o
> tivemos
> >> relatos ainda. Detalhe, portas de acesso fechadas ao mundo exterior...
> >>
> >> Em uma pesquisa r?pida esse final de semana achei muitos AS's vizinhos
> ao
> >> meu com grande parte dos acessos a CPE's expostos, e pior, muitos com
> >> credenciais padr?es ou facilmente quebr?veis, ai complica a seguran?a
> >> mesmo.
> >>
> >> Vale a pena o pessoal rever as regras de acesso a ger?ncia desses
> >> equipamentos.
> >>
> >> Em 2020-07-13 18:25, Elizandro Pacheco escreveu:
> >>
> >>> Eu estou com um C6 propositalmente exposto pra tentar pegar um
> infectado
> >> para uma an?lise melhor.
> >>>
> >>> Mas t? demorando hehe
> >>>
> >>> Elizandro Pacheco
> >>>
> >>> -----Mensagem original-----
> >>> De: gter <gter-bounces at eng.registro.br> Em nome de Lucas Willian
> >>> Bocchi Enviada em: segunda-feira, 13 de julho de 2020 18:23
> >>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> >>> <gter at eng.registro.br>
> >>> Assunto: Re: [GTER] Falhas em roteadores tp-link
> >>>
> >>> Pelo que identificamos s?o todos os que possuem aquele recurso cloud da
> >> tp-link.
> >>> A maioria s?o roteadores que est?o dentro da infra. Os nossos clientes
> >> quase todos utilizam uma solu??o de firmware aberta com OpenWRT
> >> customizado, ent?o s? conseguimos notar ou nos que trocaram os
> roteadores
> >> fornecidos pelo provedor por outros (n?o temos como negar ao cliente o
> >> direito de mudar) e que possuem vers?o cloud. Estes da linha WR-849N
> s?o os
> >> preferidos para jogar esta firmware alterada e notamos que os mais
> afetados
> >> seriam os da linha ARCHER.
> >>>
> >>> Em seg., 13 de jul. de 2020 ?s 18:12, Andre Almeida
> >>> <andre at bnet.com.br>
> >>> escreveu:
> >>>
> >>> Isso eu tamb?m queria saber.... qual o tipo do ataque.
> >>>
> >>> Em seg., 13 de jul. de 2020 ?s 17:58, Bruno Cabral
> >>> <bruno at openline.com.br>
> >>> escreveu:
> >>>
> >>> Ataque externo motivado por acesso wan sem ger?ncia, ataque externo
> >>> mesmo com medidas protetivas de wan, backdoor da nsa ou ataque
> >>> interno, estilo javascript?
> >>> ________________________________
> >>> De: gter <gter-bounces at eng.registro.br> em nome de Carlos Wander <
> >>> carlos.wander at gmail.com>
> >>> Enviado: segunda-feira, 13 de julho de 2020 17:37
> >>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> >>> gter at eng.registro.br>
> >>> Assunto: Re: [GTER] Falhas em roteadores tp-link
> >>>
> >>> Prezado Lucas,
> >>>
> >>> H? muitos coment?rios no grupos de WhatsAPP do "Loucos por Telecom",
> >> "UBNT OFICIAL", etc.
> >>>
> >>> O pessoal postou exemplos de como o ataque ocorre, coment?rios sobre a
> >>> TP-link ainda n?o ter se manifestado e dicas de como recuperar os
> >>> equipamentos.
> >>>
> >>> H? casos de provedores com mais de 2000 equipamentos afetados.
> >>>
> >>> At.te.,
> >>>
> >>> C. Wander
> >>>
> >>> Em seg., 13 de jul. de 2020 ?s 17:12, Lucas Willian Bocchi <
> >>> lucas.bocchi at gmail.com> escreveu:
> >>>
> >>> Boa tarde senhores.
> >>>
> >>> Estamos enfrentando problemas em alguns clientes com roteadores
> >>> tp-link que simplesmente pararam de funcionar ou n?o est?o funcionando
> >> direito.
> >>> Procuramos por alguma not?cia em sites nacionais sobre o problema mas
> >> n?o
> >>
> >>>> vimos nada de not?cia sobre esse problema ser uma falha de seguran?a
> >>>> ou algum ataque.
> >>>> Os senhores tiveram este problema em suas infras? Tem alguma not?cia
> >>>> oficial do assunto?
> >>>> --
> >>>> 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
> >>
> >> --
> >> Att
> >>
> >> M?rcio Elias Hahn do Nascimento
> >>
> >> [1]
> >>
> >> Links:
> >> ------
> >> [1] http://www.sulinternet.net
> >> --
> >> 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
>

From vagner at nexsul.com.br  Mon Aug 17 16:09:28 2020
From: vagner at nexsul.com.br (Vagner Felipe Becker)
Date: Mon, 17 Aug 2020 16:09:28 -0300
Subject: [GTER] RES: Rota presa AS3356 Level3
In-Reply-To: <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
Message-ID: <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>

Rota presa?! Ser? que a L3 come?ou a adotar Mikrotik no core?!

kkkk, brincadeiras a parte, tenho sess?o fechada com eles no AS3549 em 
Porto Alegre e nunca me aconteceu isso. Vou subir um peer nos p?oximos 
dias por SP via bilateral no IX no AS3356, vou testar se o problema 
ocorre e posto pra vcs.

Att,

Vagner Felipe Becker

Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
> Eu ja reclamei com o time de engenharia deles e nao tive retorno. Tenho
> esse problema a meses.
> Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
>
> Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <robson at netnew.com.br>
> escreveu:
>
>> Boa tarde
>>
>> Peguei 2 casos em lugares diferentes com o mesmo problema
>>
>> Em um, retiramos os an?ncios da sess?o com eles e o
>> outro caso foi um rompimento que derrubou a sess?o
>>
>> ambos as rotas ficaram "presas" nas consultas pelos looking glass
>> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico por outra
>> operadora
>>
>>
>>
>> Att.
>>
>> Robson F. Ramaldes
>>
>>
>> -----Mensagem original-----
>> De: gter <gter-bounces at eng.registro.br> Em nome de Charles Barreto Macedo
>> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
>> gter at eng.registro.br>
>> Assunto: Re: [GTER] Rota presa AS3356 Level3
>>
>> Bom Dia,
>>
>> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais de 6 Horas
>> para baixar os an?ncios..
>>
>> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <paivgabriel at gmail.com>
>> escreveu:
>>
>>> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da
>>> manh?, porem este ASN ainda mantem o /21 na sua tabela de roteamento e
>>> espalhando este bloco indevidamente, mesmo n?o estando sendo anunciado
>>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>
>> --
>> Atenciosamente,
>>
>> Charles Barreto
>> Zoom Telecomunica??es
>> (44) 31112-2477
>>
>> www.zoominternet.com.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
-- 

*Vagner Felipe Becker*

Nexsul Conectividade


Tel: +55(51)3712-7600 | +55(51)99754-4730

Rod. RSC 453 KM 39,5, 609 - 101, CEP 95880-000

Rio Grande do Sul, RS - Brasil


Nexsul <https://www.nexsul.com.br>


From vagnerss2011 at gmail.com  Mon Aug 17 16:40:12 2020
From: vagnerss2011 at gmail.com (vagner silva sousa)
Date: Mon, 17 Aug 2020 16:40:12 -0300
Subject: [GTER] RES: Rota presa AS3356 Level3
In-Reply-To: <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
Message-ID: <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>

Na ?poca me relataram que o problema era porque estavam migrando o AS3549
para o AS3356 e tinha um roteador no Rio de Janeiro que estava
desatualizado e estava prendendo os prefixos.

Em seg., 17 de ago. de 2020 ?s 16:09, Vagner Felipe Becker <
vagner at nexsul.com.br> escreveu:

> Rota presa?! Ser? que a L3 come?ou a adotar Mikrotik no core?!
>
> kkkk, brincadeiras a parte, tenho sess?o fechada com eles no AS3549 em
> Porto Alegre e nunca me aconteceu isso. Vou subir um peer nos p?oximos
> dias por SP via bilateral no IX no AS3356, vou testar se o problema
> ocorre e posto pra vcs.
>
> Att,
>
> Vagner Felipe Becker
>
> Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
> > Eu ja reclamei com o time de engenharia deles e nao tive retorno. Tenho
> > esse problema a meses.
> > Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
> >
> > Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <
> robson at netnew.com.br>
> > escreveu:
> >
> >> Boa tarde
> >>
> >> Peguei 2 casos em lugares diferentes com o mesmo problema
> >>
> >> Em um, retiramos os an?ncios da sess?o com eles e o
> >> outro caso foi um rompimento que derrubou a sess?o
> >>
> >> ambos as rotas ficaram "presas" nas consultas pelos looking glass
> >> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico por
> outra
> >> operadora
> >>
> >>
> >>
> >> Att.
> >>
> >> Robson F. Ramaldes
> >>
> >>
> >> -----Mensagem original-----
> >> De: gter <gter-bounces at eng.registro.br> Em nome de Charles Barreto
> Macedo
> >> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
> >> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> >> gter at eng.registro.br>
> >> Assunto: Re: [GTER] Rota presa AS3356 Level3
> >>
> >> Bom Dia,
> >>
> >> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais de 6
> Horas
> >> para baixar os an?ncios..
> >>
> >> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <
> paivgabriel at gmail.com>
> >> escreveu:
> >>
> >>> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da
> >>> manh?, porem este ASN ainda mantem o /21 na sua tabela de roteamento e
> >>> espalhando este bloco indevidamente, mesmo n?o estando sendo anunciado
> >>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
> >>> --
> >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>
> >>
> >> --
> >> Atenciosamente,
> >>
> >> Charles Barreto
> >> Zoom Telecomunica??es
> >> (44) 31112-2477
> >>
> >> www.zoominternet.com.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
> --
>
> *Vagner Felipe Becker*
>
> Nexsul Conectividade
>
>
> Tel: +55(51)3712-7600 | +55(51)99754-4730
>
> Rod. RSC 453 KM 39,5, 609 - 101, CEP 95880-000
>
> Rio Grande do Sul, RS - Brasil
>
>
> Nexsul <https://www.nexsul.com.br>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From viniciusgruske at gmail.com  Mon Aug 17 17:35:21 2020
From: viniciusgruske at gmail.com (Vinicius Gruske Dorneles)
Date: Mon, 17 Aug 2020 17:35:21 -0300
Subject: [GTER] RES: Rota presa AS3356 Level3
In-Reply-To: <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
Message-ID: <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>

Estou com um cliente do Norte do pa?s com rota presa no AS3556 nesse
exato momento. Estou tendo que anunciar o an?ncio /24, pois o /23 pela
rota presa tem AS-PATH menor que o da outra operadora. Acabei de ligar
para o suporte da Century Link, e a menina me falou que um Engenheiro
iria me retornar. Esperar para ver...

Tenho um outro cliente que fecha sess?o com o AS3549 em Porto Alegre,
que, igualmente ao relato do Vagner, n?o tem problemas com rota presa.

Mas eu percebi que esses problemas acontecem com ASNs que est?o mais
pro norte do pa?s. O que faria sentido se o problema for em um
roteador no Rio de Janeiro.

Em seg., 17 de ago. de 2020 ?s 16:40, vagner silva sousa
<vagnerss2011 at gmail.com> escreveu:
>
> Na ?poca me relataram que o problema era porque estavam migrando o AS3549
> para o AS3356 e tinha um roteador no Rio de Janeiro que estava
> desatualizado e estava prendendo os prefixos.
>
> Em seg., 17 de ago. de 2020 ?s 16:09, Vagner Felipe Becker <
> vagner at nexsul.com.br> escreveu:
>
> > Rota presa?! Ser? que a L3 come?ou a adotar Mikrotik no core?!
> >
> > kkkk, brincadeiras a parte, tenho sess?o fechada com eles no AS3549 em
> > Porto Alegre e nunca me aconteceu isso. Vou subir um peer nos p?oximos
> > dias por SP via bilateral no IX no AS3356, vou testar se o problema
> > ocorre e posto pra vcs.
> >
> > Att,
> >
> > Vagner Felipe Becker
> >
> > Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
> > > Eu ja reclamei com o time de engenharia deles e nao tive retorno. Tenho
> > > esse problema a meses.
> > > Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
> > >
> > > Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <
> > robson at netnew.com.br>
> > > escreveu:
> > >
> > >> Boa tarde
> > >>
> > >> Peguei 2 casos em lugares diferentes com o mesmo problema
> > >>
> > >> Em um, retiramos os an?ncios da sess?o com eles e o
> > >> outro caso foi um rompimento que derrubou a sess?o
> > >>
> > >> ambos as rotas ficaram "presas" nas consultas pelos looking glass
> > >> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico por
> > outra
> > >> operadora
> > >>
> > >>
> > >>
> > >> Att.
> > >>
> > >> Robson F. Ramaldes
> > >>
> > >>
> > >> -----Mensagem original-----
> > >> De: gter <gter-bounces at eng.registro.br> Em nome de Charles Barreto
> > Macedo
> > >> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
> > >> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> > >> gter at eng.registro.br>
> > >> Assunto: Re: [GTER] Rota presa AS3356 Level3
> > >>
> > >> Bom Dia,
> > >>
> > >> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais de 6
> > Horas
> > >> para baixar os an?ncios..
> > >>
> > >> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <
> > paivgabriel at gmail.com>
> > >> escreveu:
> > >>
> > >>> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da
> > >>> manh?, porem este ASN ainda mantem o /21 na sua tabela de roteamento e
> > >>> espalhando este bloco indevidamente, mesmo n?o estando sendo anunciado
> > >>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
> > >>> --
> > >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> > >>>
> > >>
> > >> --
> > >> Atenciosamente,
> > >>
> > >> Charles Barreto
> > >> Zoom Telecomunica??es
> > >> (44) 31112-2477
> > >>
> > >> www.zoominternet.com.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
> > --
> >
> > *Vagner Felipe Becker*
> >
> > Nexsul Conectividade
> >
> >
> > Tel: +55(51)3712-7600 | +55(51)99754-4730
> >
> > Rod. RSC 453 KM 39,5, 609 - 101, CEP 95880-000
> >
> > Rio Grande do Sul, RS - Brasil
> >
> >
> > Nexsul <https://www.nexsul.com.br>
> >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

From andre at bnet.com.br  Mon Aug 17 17:41:09 2020
From: andre at bnet.com.br (Andre Almeida)
Date: Mon, 17 Aug 2020 17:41:09 -0300
Subject: [GTER] RES: Rota presa AS3356 Level3
In-Reply-To: <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
 <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
Message-ID: <CAKAeHyHM_QXXMsq-9XOkZbH5ehuWAgScu-yz+a8gMBh7SJeypQ@mail.gmail.com>

Aqui no Oeste do RS tamb?m temos transito com a CenturyLink e n?o temos
problemas desse tipo.
Deve ser mais pro norte mesmo.

From leandropds at gmail.com  Mon Aug 17 16:59:05 2020
From: leandropds at gmail.com (Leandro Santos)
Date: Mon, 17 Aug 2020 16:59:05 -0300
Subject: [GTER] RES: Rota presa AS3356 Level3
In-Reply-To: <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
Message-ID: <CACT05r5+0Y+xeAQ+eVjD98zA6sBF2WnZ=7b+0c3QfDwHK99PYQ@mail.gmail.com>

Temos esse problema a mais de 1 ano na regi?o centro-oeste. Brasilia e
Goias, abrimos diversos chamados e nada de resolver, j? instrui todos os
clientes a cancelar o contrato e buscar outra op??o.

Em seg., 17 de ago. de 2020 ?s 16:40, vagner silva sousa <
vagnerss2011 at gmail.com> escreveu:

> Na ?poca me relataram que o problema era porque estavam migrando o AS3549
> para o AS3356 e tinha um roteador no Rio de Janeiro que estava
> desatualizado e estava prendendo os prefixos.
>
> Em seg., 17 de ago. de 2020 ?s 16:09, Vagner Felipe Becker <
> vagner at nexsul.com.br> escreveu:
>
> > Rota presa?! Ser? que a L3 come?ou a adotar Mikrotik no core?!
> >
> > kkkk, brincadeiras a parte, tenho sess?o fechada com eles no AS3549 em
> > Porto Alegre e nunca me aconteceu isso. Vou subir um peer nos p?oximos
> > dias por SP via bilateral no IX no AS3356, vou testar se o problema
> > ocorre e posto pra vcs.
> >
> > Att,
> >
> > Vagner Felipe Becker
> >
> > Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
> > > Eu ja reclamei com o time de engenharia deles e nao tive retorno. Tenho
> > > esse problema a meses.
> > > Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
> > >
> > > Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <
> > robson at netnew.com.br>
> > > escreveu:
> > >
> > >> Boa tarde
> > >>
> > >> Peguei 2 casos em lugares diferentes com o mesmo problema
> > >>
> > >> Em um, retiramos os an?ncios da sess?o com eles e o
> > >> outro caso foi um rompimento que derrubou a sess?o
> > >>
> > >> ambos as rotas ficaram "presas" nas consultas pelos looking glass
> > >> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico por
> > outra
> > >> operadora
> > >>
> > >>
> > >>
> > >> Att.
> > >>
> > >> Robson F. Ramaldes
> > >>
> > >>
> > >> -----Mensagem original-----
> > >> De: gter <gter-bounces at eng.registro.br> Em nome de Charles Barreto
> > Macedo
> > >> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
> > >> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> > >> gter at eng.registro.br>
> > >> Assunto: Re: [GTER] Rota presa AS3356 Level3
> > >>
> > >> Bom Dia,
> > >>
> > >> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais de 6
> > Horas
> > >> para baixar os an?ncios..
> > >>
> > >> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <
> > paivgabriel at gmail.com>
> > >> escreveu:
> > >>
> > >>> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da
> > >>> manh?, porem este ASN ainda mantem o /21 na sua tabela de roteamento
> e
> > >>> espalhando este bloco indevidamente, mesmo n?o estando sendo
> anunciado
> > >>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
> > >>> --
> > >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> > >>>
> > >>
> > >> --
> > >> Atenciosamente,
> > >>
> > >> Charles Barreto
> > >> Zoom Telecomunica??es
> > >> (44) 31112-2477
> > >>
> > >> www.zoominternet.com.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
> > --
> >
> > *Vagner Felipe Becker*
> >
> > Nexsul Conectividade
> >
> >
> > Tel: +55(51)3712-7600 | +55(51)99754-4730
> >
> > Rod. RSC 453 KM 39,5, 609 - 101, CEP 95880-000
> >
> > Rio Grande do Sul, RS - Brasil
> >
> >
> > Nexsul <https://www.nexsul.com.br>
> >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From joao at naxi.com.br  Tue Aug 18 15:29:33 2020
From: joao at naxi.com.br (=?UTF-8?Q?Jo=c3=a3o_Butzke?=)
Date: Tue, 18 Aug 2020 15:29:33 -0300
Subject: [GTER] RES: Rota presa AS3356 Level3
In-Reply-To: <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
 <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
Message-ID: <95b7c0ba-0319-1941-c361-21aa904567c9@naxi.com.br>

Acontece aqui no sul tambem, n?o ? privil?gio do norte rsrsrsrs

Att,

Em 17/08/2020 17:35, Vinicius Gruske Dorneles escreveu:
> Estou com um cliente do Norte do pa?s com rota presa no AS3556 nesse
> exato momento. Estou tendo que anunciar o an?ncio /24, pois o /23 pela
> rota presa tem AS-PATH menor que o da outra operadora. Acabei de ligar
> para o suporte da Century Link, e a menina me falou que um Engenheiro
> iria me retornar. Esperar para ver...
>
> Tenho um outro cliente que fecha sess?o com o AS3549 em Porto Alegre,
> que, igualmente ao relato do Vagner, n?o tem problemas com rota presa.
>
> Mas eu percebi que esses problemas acontecem com ASNs que est?o mais
> pro norte do pa?s. O que faria sentido se o problema for em um
> roteador no Rio de Janeiro.
>
> Em seg., 17 de ago. de 2020 ?s 16:40, vagner silva sousa
> <vagnerss2011 at gmail.com> escreveu:
>> Na ?poca me relataram que o problema era porque estavam migrando o AS3549
>> para o AS3356 e tinha um roteador no Rio de Janeiro que estava
>> desatualizado e estava prendendo os prefixos.
>>
>> Em seg., 17 de ago. de 2020 ?s 16:09, Vagner Felipe Becker <
>> vagner at nexsul.com.br> escreveu:
>>
>>> Rota presa?! Ser? que a L3 come?ou a adotar Mikrotik no core?!
>>>
>>> kkkk, brincadeiras a parte, tenho sess?o fechada com eles no AS3549 em
>>> Porto Alegre e nunca me aconteceu isso. Vou subir um peer nos p?oximos
>>> dias por SP via bilateral no IX no AS3356, vou testar se o problema
>>> ocorre e posto pra vcs.
>>>
>>> Att,
>>>
>>> Vagner Felipe Becker
>>>
>>> Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
>>>> Eu ja reclamei com o time de engenharia deles e nao tive retorno. Tenho
>>>> esse problema a meses.
>>>> Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
>>>>
>>>> Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <
>>> robson at netnew.com.br>
>>>> escreveu:
>>>>
>>>>> Boa tarde
>>>>>
>>>>> Peguei 2 casos em lugares diferentes com o mesmo problema
>>>>>
>>>>> Em um, retiramos os an?ncios da sess?o com eles e o
>>>>> outro caso foi um rompimento que derrubou a sess?o
>>>>>
>>>>> ambos as rotas ficaram "presas" nas consultas pelos looking glass
>>>>> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico por
>>> outra
>>>>> operadora
>>>>>
>>>>>
>>>>>
>>>>> Att.
>>>>>
>>>>> Robson F. Ramaldes
>>>>>
>>>>>
>>>>> -----Mensagem original-----
>>>>> De: gter <gter-bounces at eng.registro.br> Em nome de Charles Barreto
>>> Macedo
>>>>> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
>>>>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
>>>>> gter at eng.registro.br>
>>>>> Assunto: Re: [GTER] Rota presa AS3356 Level3
>>>>>
>>>>> Bom Dia,
>>>>>
>>>>> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais de 6
>>> Horas
>>>>> para baixar os an?ncios..
>>>>>
>>>>> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <
>>> paivgabriel at gmail.com>
>>>>> escreveu:
>>>>>
>>>>>> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da
>>>>>> manh?, porem este ASN ainda mantem o /21 na sua tabela de roteamento e
>>>>>> espalhando este bloco indevidamente, mesmo n?o estando sendo anunciado
>>>>>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
>>>>>> --
>>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>>>
>>>>> --
>>>>> Atenciosamente,
>>>>>
>>>>> Charles Barreto
>>>>> Zoom Telecomunica??es
>>>>> (44) 31112-2477
>>>>>
>>>>> www.zoominternet.com.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
>>> --
>>>
>>> *Vagner Felipe Becker*
>>>
>>> Nexsul Conectividade
>>>
>>>
>>> Tel: +55(51)3712-7600 | +55(51)99754-4730
>>>
>>> Rod. RSC 453 KM 39,5, 609 - 101, CEP 95880-000
>>>
>>> Rio Grande do Sul, RS - Brasil
>>>
>>>
>>> Nexsul <https://www.nexsul.com.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

From alyssonjose at gmail.com  Tue Aug 18 15:50:05 2020
From: alyssonjose at gmail.com (Alysson Jose da Silva)
Date: Tue, 18 Aug 2020 15:50:05 -0300
Subject: [GTER] RES: Rota presa AS3356 Level3
In-Reply-To: <95b7c0ba-0319-1941-c361-21aa904567c9@naxi.com.br>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
 <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
 <95b7c0ba-0319-1941-c361-21aa904567c9@naxi.com.br>
Message-ID: <df36b6c6-0b81-4b5d-1e32-c8cef40d2b26@gmail.com>

Aconteceu aqui tamb?m, mas no AS 3549

triste....

Em 18/08/2020 15:29, Jo?o Butzke escreveu:
> Acontece aqui no sul tambem, n?o ? privil?gio do norte rsrsrsrs
>
> Att,
>
> Em 17/08/2020 17:35, Vinicius Gruske Dorneles escreveu:
>> Estou com um cliente do Norte do pa?s com rota presa no AS3556 nesse
>> exato momento. Estou tendo que anunciar o an?ncio /24, pois o /23 pela
>> rota presa tem AS-PATH menor que o da outra operadora. Acabei de ligar
>> para o suporte da Century Link, e a menina me falou que um Engenheiro
>> iria me retornar. Esperar para ver...
>>
>> Tenho um outro cliente que fecha sess?o com o AS3549 em Porto Alegre,
>> que, igualmente ao relato do Vagner, n?o tem problemas com rota presa.
>>
>> Mas eu percebi que esses problemas acontecem com ASNs que est?o mais
>> pro norte do pa?s. O que faria sentido se o problema for em um
>> roteador no Rio de Janeiro.
>>
>> Em seg., 17 de ago. de 2020 ?s 16:40, vagner silva sousa
>> <vagnerss2011 at gmail.com> escreveu:
>>> Na ?poca me relataram que o problema era porque estavam migrando o 
>>> AS3549
>>> para o AS3356 e tinha um roteador no Rio de Janeiro que estava
>>> desatualizado e estava prendendo os prefixos.
>>>
>>> Em seg., 17 de ago. de 2020 ?s 16:09, Vagner Felipe Becker <
>>> vagner at nexsul.com.br> escreveu:
>>>
>>>> Rota presa?! Ser? que a L3 come?ou a adotar Mikrotik no core?!
>>>>
>>>> kkkk, brincadeiras a parte, tenho sess?o fechada com eles no AS3549 em
>>>> Porto Alegre e nunca me aconteceu isso. Vou subir um peer nos p?oximos
>>>> dias por SP via bilateral no IX no AS3356, vou testar se o problema
>>>> ocorre e posto pra vcs.
>>>>
>>>> Att,
>>>>
>>>> Vagner Felipe Becker
>>>>
>>>> Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
>>>>> Eu ja reclamei com o time de engenharia deles e nao tive retorno. 
>>>>> Tenho
>>>>> esse problema a meses.
>>>>> Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
>>>>>
>>>>> Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <
>>>> robson at netnew.com.br>
>>>>> escreveu:
>>>>>
>>>>>> Boa tarde
>>>>>>
>>>>>> Peguei 2 casos em lugares diferentes com o mesmo problema
>>>>>>
>>>>>> Em um, retiramos os an?ncios da sess?o com eles e o
>>>>>> outro caso foi um rompimento que derrubou a sess?o
>>>>>>
>>>>>> ambos as rotas ficaram "presas" nas consultas pelos looking glass
>>>>>> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico por
>>>> outra
>>>>>> operadora
>>>>>>
>>>>>>
>>>>>>
>>>>>> Att.
>>>>>>
>>>>>> Robson F. Ramaldes
>>>>>>
>>>>>>
>>>>>> -----Mensagem original-----
>>>>>> De: gter <gter-bounces at eng.registro.br> Em nome de Charles Barreto
>>>> Macedo
>>>>>> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
>>>>>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
>>>>>> gter at eng.registro.br>
>>>>>> Assunto: Re: [GTER] Rota presa AS3356 Level3
>>>>>>
>>>>>> Bom Dia,
>>>>>>
>>>>>> Para n?s, ? um problema antigo...? J? aconteceu de demorar mais de 6
>>>> Horas
>>>>>> para baixar os an?ncios..
>>>>>>
>>>>>> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <
>>>> paivgabriel at gmail.com>
>>>>>> escreveu:
>>>>>>
>>>>>>> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 
>>>>>>> 6 da
>>>>>>> manh?, porem este ASN ainda mantem o /21 na sua tabela de 
>>>>>>> roteamento e
>>>>>>> espalhando este bloco indevidamente, mesmo n?o estando sendo 
>>>>>>> anunciado
>>>>>>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
>>>>>>> -- 
>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>>>>>>>
>>>>>> -- 
>>>>>> Atenciosamente,
>>>>>>
>>>>>> Charles Barreto
>>>>>> Zoom Telecomunica??es
>>>>>> (44) 31112-2477
>>>>>>
>>>>>> www.zoominternet.com.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
>>>> -- 
>>>>
>>>> *Vagner Felipe Becker*
>>>>
>>>> Nexsul Conectividade
>>>>
>>>>
>>>> Tel: +55(51)3712-7600 | +55(51)99754-4730
>>>>
>>>> Rod. RSC 453 KM 39,5, 609 - 101, CEP 95880-000
>>>>
>>>> Rio Grande do Sul, RS - Brasil
>>>>
>>>>
>>>> Nexsul <https://www.nexsul.com.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

From alexandre at opticalhost.com.br  Tue Aug 18 16:31:07 2020
From: alexandre at opticalhost.com.br (Alexandre Aleixo | Opticalhost)
Date: Tue, 18 Aug 2020 16:31:07 -0300
Subject: [GTER] RES: Rota presa AS3356 Level3
In-Reply-To: <df36b6c6-0b81-4b5d-1e32-c8cef40d2b26@gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
 <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
 <95b7c0ba-0319-1941-c361-21aa904567c9@naxi.com.br>
 <df36b6c6-0b81-4b5d-1e32-c8cef40d2b26@gmail.com>
Message-ID: <CAO4k366S7kcT7Lfg11H9H8a+TfTusfUtiQjjtgzcMmMtKdkSRg@mail.gmail.com>

N?o tem ningu?m aqui da L3 que possa ver isso?

Parece algo t?o simples, como uma configura??o de "hold time" do
keepalive em menor tempo, pra que a sess?o seja derrubada mais
rapidamente...

Alexandre Aleixo




Em ter., 18 de ago. de 2020 ?s 15:50, Alysson Jose da Silva <
alyssonjose at gmail.com> escreveu:

> Aconteceu aqui tamb?m, mas no AS 3549
>
> triste....
>
> Em 18/08/2020 15:29, Jo?o Butzke escreveu:
> > Acontece aqui no sul tambem, n?o ? privil?gio do norte rsrsrsrs
> >
> > Att,
> >
> > Em 17/08/2020 17:35, Vinicius Gruske Dorneles escreveu:
> >> Estou com um cliente do Norte do pa?s com rota presa no AS3556 nesse
> >> exato momento. Estou tendo que anunciar o an?ncio /24, pois o /23 pela
> >> rota presa tem AS-PATH menor que o da outra operadora. Acabei de ligar
> >> para o suporte da Century Link, e a menina me falou que um Engenheiro
> >> iria me retornar. Esperar para ver...
> >>
> >> Tenho um outro cliente que fecha sess?o com o AS3549 em Porto Alegre,
> >> que, igualmente ao relato do Vagner, n?o tem problemas com rota presa.
> >>
> >> Mas eu percebi que esses problemas acontecem com ASNs que est?o mais
> >> pro norte do pa?s. O que faria sentido se o problema for em um
> >> roteador no Rio de Janeiro.
> >>
> >> Em seg., 17 de ago. de 2020 ?s 16:40, vagner silva sousa
> >> <vagnerss2011 at gmail.com> escreveu:
> >>> Na ?poca me relataram que o problema era porque estavam migrando o
> >>> AS3549
> >>> para o AS3356 e tinha um roteador no Rio de Janeiro que estava
> >>> desatualizado e estava prendendo os prefixos.
> >>>
> >>> Em seg., 17 de ago. de 2020 ?s 16:09, Vagner Felipe Becker <
> >>> vagner at nexsul.com.br> escreveu:
> >>>
> >>>> Rota presa?! Ser? que a L3 come?ou a adotar Mikrotik no core?!
> >>>>
> >>>> kkkk, brincadeiras a parte, tenho sess?o fechada com eles no AS3549 em
> >>>> Porto Alegre e nunca me aconteceu isso. Vou subir um peer nos p?oximos
> >>>> dias por SP via bilateral no IX no AS3356, vou testar se o problema
> >>>> ocorre e posto pra vcs.
> >>>>
> >>>> Att,
> >>>>
> >>>> Vagner Felipe Becker
> >>>>
> >>>> Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
> >>>>> Eu ja reclamei com o time de engenharia deles e nao tive retorno.
> >>>>> Tenho
> >>>>> esse problema a meses.
> >>>>> Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
> >>>>>
> >>>>> Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <
> >>>> robson at netnew.com.br>
> >>>>> escreveu:
> >>>>>
> >>>>>> Boa tarde
> >>>>>>
> >>>>>> Peguei 2 casos em lugares diferentes com o mesmo problema
> >>>>>>
> >>>>>> Em um, retiramos os an?ncios da sess?o com eles e o
> >>>>>> outro caso foi um rompimento que derrubou a sess?o
> >>>>>>
> >>>>>> ambos as rotas ficaram "presas" nas consultas pelos looking glass
> >>>>>> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico por
> >>>> outra
> >>>>>> operadora
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Att.
> >>>>>>
> >>>>>> Robson F. Ramaldes
> >>>>>>
> >>>>>>
> >>>>>> -----Mensagem original-----
> >>>>>> De: gter <gter-bounces at eng.registro.br> Em nome de Charles Barreto
> >>>> Macedo
> >>>>>> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
> >>>>>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> >>>>>> gter at eng.registro.br>
> >>>>>> Assunto: Re: [GTER] Rota presa AS3356 Level3
> >>>>>>
> >>>>>> Bom Dia,
> >>>>>>
> >>>>>> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais de 6
> >>>> Horas
> >>>>>> para baixar os an?ncios..
> >>>>>>
> >>>>>> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <
> >>>> paivgabriel at gmail.com>
> >>>>>> escreveu:
> >>>>>>
> >>>>>>> N?s paramos de anunciar para nossos upstreams um /21 inteiro as
> >>>>>>> 6 da
> >>>>>>> manh?, porem este ASN ainda mantem o /21 na sua tabela de
> >>>>>>> roteamento e
> >>>>>>> espalhando este bloco indevidamente, mesmo n?o estando sendo
> >>>>>>> anunciado
> >>>>>>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
> >>>>>>> --
> >>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
> >>>>>>>
> >>>>>> --
> >>>>>> Atenciosamente,
> >>>>>>
> >>>>>> Charles Barreto
> >>>>>> Zoom Telecomunica??es
> >>>>>> (44) 31112-2477
> >>>>>>
> >>>>>> www.zoominternet.com.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
> >>>> --
> >>>>
> >>>> *Vagner Felipe Becker*
> >>>>
> >>>> Nexsul Conectividade
> >>>>
> >>>>
> >>>> Tel: +55(51)3712-7600 | +55(51)99754-4730
> >>>>
> >>>> Rod. RSC 453 KM 39,5, 609 - 101, CEP 95880-000
> >>>>
> >>>> Rio Grande do Sul, RS - Brasil
> >>>>
> >>>>
> >>>> Nexsul <https://www.nexsul.com.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
>

From lucas.bocchi at gmail.com  Tue Aug 18 16:40:41 2020
From: lucas.bocchi at gmail.com (Lucas Willian Bocchi)
Date: Tue, 18 Aug 2020 16:40:41 -0300
Subject: [GTER] RES: Rota presa AS3356 Level3
In-Reply-To: <CAO4k366S7kcT7Lfg11H9H8a+TfTusfUtiQjjtgzcMmMtKdkSRg@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
 <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
 <95b7c0ba-0319-1941-c361-21aa904567c9@naxi.com.br>
 <df36b6c6-0b81-4b5d-1e32-c8cef40d2b26@gmail.com>
 <CAO4k366S7kcT7Lfg11H9H8a+TfTusfUtiQjjtgzcMmMtKdkSRg@mail.gmail.com>
Message-ID: <CA+m52=fnMt+qkK2uvJD5prVwb7SSz-kge5_zPZu0NXoKxkGb7g@mail.gmail.com>

N?o tem pessoal.
J? falei com eles v?rias vezes numa boa e nunca consegui resolver. Tenho 6
ou 7 provedores com o mesmo problema. Alguns nem tem TR?NSITO com a Level3
mas eles acabam prendendo a rota mesmo assim. N?s vamos enviar uma
notifica??o extra-judicial em nome de todos esses provedores. Vemos que ? a
?nica forma de resolver.

Em ter., 18 de ago. de 2020 ?s 16:32, Alexandre Aleixo | Opticalhost <
alexandre at opticalhost.com.br> escreveu:

> N?o tem ningu?m aqui da L3 que possa ver isso?
>
> Parece algo t?o simples, como uma configura??o de "hold time" do
> keepalive em menor tempo, pra que a sess?o seja derrubada mais
> rapidamente...
>
> Alexandre Aleixo
>
>
>
>
> Em ter., 18 de ago. de 2020 ?s 15:50, Alysson Jose da Silva <
> alyssonjose at gmail.com> escreveu:
>
> > Aconteceu aqui tamb?m, mas no AS 3549
> >
> > triste....
> >
> > Em 18/08/2020 15:29, Jo?o Butzke escreveu:
> > > Acontece aqui no sul tambem, n?o ? privil?gio do norte rsrsrsrs
> > >
> > > Att,
> > >
> > > Em 17/08/2020 17:35, Vinicius Gruske Dorneles escreveu:
> > >> Estou com um cliente do Norte do pa?s com rota presa no AS3556 nesse
> > >> exato momento. Estou tendo que anunciar o an?ncio /24, pois o /23 pela
> > >> rota presa tem AS-PATH menor que o da outra operadora. Acabei de ligar
> > >> para o suporte da Century Link, e a menina me falou que um Engenheiro
> > >> iria me retornar. Esperar para ver...
> > >>
> > >> Tenho um outro cliente que fecha sess?o com o AS3549 em Porto Alegre,
> > >> que, igualmente ao relato do Vagner, n?o tem problemas com rota presa.
> > >>
> > >> Mas eu percebi que esses problemas acontecem com ASNs que est?o mais
> > >> pro norte do pa?s. O que faria sentido se o problema for em um
> > >> roteador no Rio de Janeiro.
> > >>
> > >> Em seg., 17 de ago. de 2020 ?s 16:40, vagner silva sousa
> > >> <vagnerss2011 at gmail.com> escreveu:
> > >>> Na ?poca me relataram que o problema era porque estavam migrando o
> > >>> AS3549
> > >>> para o AS3356 e tinha um roteador no Rio de Janeiro que estava
> > >>> desatualizado e estava prendendo os prefixos.
> > >>>
> > >>> Em seg., 17 de ago. de 2020 ?s 16:09, Vagner Felipe Becker <
> > >>> vagner at nexsul.com.br> escreveu:
> > >>>
> > >>>> Rota presa?! Ser? que a L3 come?ou a adotar Mikrotik no core?!
> > >>>>
> > >>>> kkkk, brincadeiras a parte, tenho sess?o fechada com eles no AS3549
> em
> > >>>> Porto Alegre e nunca me aconteceu isso. Vou subir um peer nos
> p?oximos
> > >>>> dias por SP via bilateral no IX no AS3356, vou testar se o problema
> > >>>> ocorre e posto pra vcs.
> > >>>>
> > >>>> Att,
> > >>>>
> > >>>> Vagner Felipe Becker
> > >>>>
> > >>>> Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
> > >>>>> Eu ja reclamei com o time de engenharia deles e nao tive retorno.
> > >>>>> Tenho
> > >>>>> esse problema a meses.
> > >>>>> Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
> > >>>>>
> > >>>>> Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <
> > >>>> robson at netnew.com.br>
> > >>>>> escreveu:
> > >>>>>
> > >>>>>> Boa tarde
> > >>>>>>
> > >>>>>> Peguei 2 casos em lugares diferentes com o mesmo problema
> > >>>>>>
> > >>>>>> Em um, retiramos os an?ncios da sess?o com eles e o
> > >>>>>> outro caso foi um rompimento que derrubou a sess?o
> > >>>>>>
> > >>>>>> ambos as rotas ficaram "presas" nas consultas pelos looking glass
> > >>>>>> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico
> por
> > >>>> outra
> > >>>>>> operadora
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Att.
> > >>>>>>
> > >>>>>> Robson F. Ramaldes
> > >>>>>>
> > >>>>>>
> > >>>>>> -----Mensagem original-----
> > >>>>>> De: gter <gter-bounces at eng.registro.br> Em nome de Charles
> Barreto
> > >>>> Macedo
> > >>>>>> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
> > >>>>>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> > >>>>>> gter at eng.registro.br>
> > >>>>>> Assunto: Re: [GTER] Rota presa AS3356 Level3
> > >>>>>>
> > >>>>>> Bom Dia,
> > >>>>>>
> > >>>>>> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais
> de 6
> > >>>> Horas
> > >>>>>> para baixar os an?ncios..
> > >>>>>>
> > >>>>>> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <
> > >>>> paivgabriel at gmail.com>
> > >>>>>> escreveu:
> > >>>>>>
> > >>>>>>> N?s paramos de anunciar para nossos upstreams um /21 inteiro as
> > >>>>>>> 6 da
> > >>>>>>> manh?, porem este ASN ainda mantem o /21 na sua tabela de
> > >>>>>>> roteamento e
> > >>>>>>> espalhando este bloco indevidamente, mesmo n?o estando sendo
> > >>>>>>> anunciado
> > >>>>>>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
> > >>>>>>> --
> > >>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
> > >>>>>>>
> > >>>>>> --
> > >>>>>> Atenciosamente,
> > >>>>>>
> > >>>>>> Charles Barreto
> > >>>>>> Zoom Telecomunica??es
> > >>>>>> (44) 31112-2477
> > >>>>>>
> > >>>>>> www.zoominternet.com.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
> > >>>> --
> > >>>>
> > >>>> *Vagner Felipe Becker*
> > >>>>
> > >>>> Nexsul Conectividade
> > >>>>
> > >>>>
> > >>>> Tel: +55(51)3712-7600 | +55(51)99754-4730
> > >>>>
> > >>>> Rod. RSC 453 KM 39,5, 609 - 101, CEP 95880-000
> > >>>>
> > >>>> Rio Grande do Sul, RS - Brasil
> > >>>>
> > >>>>
> > >>>> Nexsul <https://www.nexsul.com.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
>

From edinilson at atinet.com.br  Tue Aug 18 15:50:19 2020
From: edinilson at atinet.com.br (Edinilson J. Santos)
Date: Tue, 18 Aug 2020 15:50:19 -0300
Subject: [GTER] Rota presa AS3356 Level3
In-Reply-To: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
Message-ID: <91a24063-d3a5-69d5-a648-5928647043f4@atinet.com.br>

Em 17/08/2020 11:16, Gabriel Wolp escreveu:
> N?s paramos de anunciar para nossos upstreams um /21 inteiro as 6 da manh?,
> porem este ASN ainda mantem o /21 na sua tabela de roteamento e espalhando
> este bloco indevidamente, mesmo n?o estando sendo anunciado para nenhum de
> nossos upstreams. J? aconteceu isso com algu?m?
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

Quando ocorrer, poste l? na lista CAIU (que n?o ? moderada como a GTER e tem entrega mais r?pida) para que outros com link da Level3/Centurylink acompanhar.

N?o percebi esse problema aqui at? o momento (n?o quer dizer que n?o esteja acontecendo).

Edinilson

From contato at gomais.com.br  Tue Aug 18 16:43:36 2020
From: contato at gomais.com.br (contato at gomais.com.br)
Date: Tue, 18 Aug 2020 16:43:36 -0300
Subject: [GTER] RES: Rota presa AS3356 Level3
In-Reply-To: <CA+m52=fnMt+qkK2uvJD5prVwb7SSz-kge5_zPZu0NXoKxkGb7g@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
 <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
 <95b7c0ba-0319-1941-c361-21aa904567c9@naxi.com.br>
 <df36b6c6-0b81-4b5d-1e32-c8cef40d2b26@gmail.com>
 <CAO4k366S7kcT7Lfg11H9H8a+TfTusfUtiQjjtgzcMmMtKdkSRg@mail.gmail.com>
 <CA+m52=fnMt+qkK2uvJD5prVwb7SSz-kge5_zPZu0NXoKxkGb7g@mail.gmail.com>
Message-ID: <9f408064-a062-8f07-c180-6e6a9d132e5f@gomais.com.br>

eles est?o sobre forte ataques por isso est? esse caos.
estou com dois provedores usa Level3 direto
somados est?o recebendo 1tera de ataque

Em 18/08/2020 16:40, Lucas Willian Bocchi escreveu:
> N?o tem pessoal.
> J? falei com eles v?rias vezes numa boa e nunca consegui resolver. Tenho 6
> ou 7 provedores com o mesmo problema. Alguns nem tem TR?NSITO com a Level3
> mas eles acabam prendendo a rota mesmo assim. N?s vamos enviar uma
> notifica??o extra-judicial em nome de todos esses provedores. Vemos que ? a
> ?nica forma de resolver.
>
> Em ter., 18 de ago. de 2020 ?s 16:32, Alexandre Aleixo | Opticalhost <
> alexandre at opticalhost.com.br> escreveu:
>
>> N?o tem ningu?m aqui da L3 que possa ver isso?
>>
>> Parece algo t?o simples, como uma configura??o de "hold time" do
>> keepalive em menor tempo, pra que a sess?o seja derrubada mais
>> rapidamente...
>>
>> Alexandre Aleixo
>>
>>
>>
>>
>> Em ter., 18 de ago. de 2020 ?s 15:50, Alysson Jose da Silva <
>> alyssonjose at gmail.com> escreveu:
>>
>>> Aconteceu aqui tamb?m, mas no AS 3549
>>>
>>> triste....
>>>
>>> Em 18/08/2020 15:29, Jo?o Butzke escreveu:
>>>> Acontece aqui no sul tambem, n?o ? privil?gio do norte rsrsrsrs
>>>>
>>>> Att,
>>>>
>>>> Em 17/08/2020 17:35, Vinicius Gruske Dorneles escreveu:
>>>>> Estou com um cliente do Norte do pa?s com rota presa no AS3556 nesse
>>>>> exato momento. Estou tendo que anunciar o an?ncio /24, pois o /23 pela
>>>>> rota presa tem AS-PATH menor que o da outra operadora. Acabei de ligar
>>>>> para o suporte da Century Link, e a menina me falou que um Engenheiro
>>>>> iria me retornar. Esperar para ver...
>>>>>
>>>>> Tenho um outro cliente que fecha sess?o com o AS3549 em Porto Alegre,
>>>>> que, igualmente ao relato do Vagner, n?o tem problemas com rota presa.
>>>>>
>>>>> Mas eu percebi que esses problemas acontecem com ASNs que est?o mais
>>>>> pro norte do pa?s. O que faria sentido se o problema for em um
>>>>> roteador no Rio de Janeiro.
>>>>>
>>>>> Em seg., 17 de ago. de 2020 ?s 16:40, vagner silva sousa
>>>>> <vagnerss2011 at gmail.com> escreveu:
>>>>>> Na ?poca me relataram que o problema era porque estavam migrando o
>>>>>> AS3549
>>>>>> para o AS3356 e tinha um roteador no Rio de Janeiro que estava
>>>>>> desatualizado e estava prendendo os prefixos.
>>>>>>
>>>>>> Em seg., 17 de ago. de 2020 ?s 16:09, Vagner Felipe Becker <
>>>>>> vagner at nexsul.com.br> escreveu:
>>>>>>
>>>>>>> Rota presa?! Ser? que a L3 come?ou a adotar Mikrotik no core?!
>>>>>>>
>>>>>>> kkkk, brincadeiras a parte, tenho sess?o fechada com eles no AS3549
>> em
>>>>>>> Porto Alegre e nunca me aconteceu isso. Vou subir um peer nos
>> p?oximos
>>>>>>> dias por SP via bilateral no IX no AS3356, vou testar se o problema
>>>>>>> ocorre e posto pra vcs.
>>>>>>>
>>>>>>> Att,
>>>>>>>
>>>>>>> Vagner Felipe Becker
>>>>>>>
>>>>>>> Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
>>>>>>>> Eu ja reclamei com o time de engenharia deles e nao tive retorno.
>>>>>>>> Tenho
>>>>>>>> esse problema a meses.
>>>>>>>> Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
>>>>>>>>
>>>>>>>> Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <
>>>>>>> robson at netnew.com.br>
>>>>>>>> escreveu:
>>>>>>>>
>>>>>>>>> Boa tarde
>>>>>>>>>
>>>>>>>>> Peguei 2 casos em lugares diferentes com o mesmo problema
>>>>>>>>>
>>>>>>>>> Em um, retiramos os an?ncios da sess?o com eles e o
>>>>>>>>> outro caso foi um rompimento que derrubou a sess?o
>>>>>>>>>
>>>>>>>>> ambos as rotas ficaram "presas" nas consultas pelos looking glass
>>>>>>>>> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico
>> por
>>>>>>> outra
>>>>>>>>> operadora
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Att.
>>>>>>>>>
>>>>>>>>> Robson F. Ramaldes
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Mensagem original-----
>>>>>>>>> De: gter <gter-bounces at eng.registro.br> Em nome de Charles
>> Barreto
>>>>>>> Macedo
>>>>>>>>> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
>>>>>>>>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
>>>>>>>>> gter at eng.registro.br>
>>>>>>>>> Assunto: Re: [GTER] Rota presa AS3356 Level3
>>>>>>>>>
>>>>>>>>> Bom Dia,
>>>>>>>>>
>>>>>>>>> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais
>> de 6
>>>>>>> Horas
>>>>>>>>> para baixar os an?ncios..
>>>>>>>>>
>>>>>>>>> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <
>>>>>>> paivgabriel at gmail.com>
>>>>>>>>> escreveu:
>>>>>>>>>
>>>>>>>>>> N?s paramos de anunciar para nossos upstreams um /21 inteiro as
>>>>>>>>>> 6 da
>>>>>>>>>> manh?, porem este ASN ainda mantem o /21 na sua tabela de
>>>>>>>>>> roteamento e
>>>>>>>>>> espalhando este bloco indevidamente, mesmo n?o estando sendo
>>>>>>>>>> anunciado
>>>>>>>>>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
>>>>>>>>>> --
>>>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Atenciosamente,
>>>>>>>>>
>>>>>>>>> Charles Barreto
>>>>>>>>> Zoom Telecomunica??es
>>>>>>>>> (44) 31112-2477
>>>>>>>>>
>>>>>>>>> www.zoominternet.com.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
>>>>>>> --
>>>>>>>
>>>>>>> *Vagner Felipe Becker*
>>>>>>>
>>>>>>> Nexsul Conectividade
>>>>>>>
>>>>>>>
>>>>>>> Tel: +55(51)3712-7600 | +55(51)99754-4730
>>>>>>>
>>>>>>> Rod. RSC 453 KM 39,5, 609 - 101, CEP 95880-000
>>>>>>>
>>>>>>> Rio Grande do Sul, RS - Brasil
>>>>>>>
>>>>>>>
>>>>>>> Nexsul <https://www.nexsul.com.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
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

From lucas.bocchi at gmail.com  Tue Aug 18 18:15:31 2020
From: lucas.bocchi at gmail.com (Lucas Willian Bocchi)
Date: Tue, 18 Aug 2020 18:15:31 -0300
Subject: [GTER] RES: Rota presa AS3356 Level3
In-Reply-To: <9f408064-a062-8f07-c180-6e6a9d132e5f@gomais.com.br>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
 <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
 <95b7c0ba-0319-1941-c361-21aa904567c9@naxi.com.br>
 <df36b6c6-0b81-4b5d-1e32-c8cef40d2b26@gmail.com>
 <CAO4k366S7kcT7Lfg11H9H8a+TfTusfUtiQjjtgzcMmMtKdkSRg@mail.gmail.com>
 <CA+m52=fnMt+qkK2uvJD5prVwb7SSz-kge5_zPZu0NXoKxkGb7g@mail.gmail.com>
 <9f408064-a062-8f07-c180-6e6a9d132e5f@gomais.com.br>
Message-ID: <CA+m52=c51ZTo9o5uhnjQtj6ewJA9ufM6DCohrRDPA68unrKmzQ@mail.gmail.com>

De onde surgiu essa informa??o nobre? ? de fonte segura?
Aqui pra mim ningu?m da equipe deles confirmou.

Em ter., 18 de ago. de 2020 ?s 16:52, contato at gomais.com.br <
contato at gomais.com.br> escreveu:

> eles est?o sobre forte ataques por isso est? esse caos.
> estou com dois provedores usa Level3 direto
> somados est?o recebendo 1tera de ataque
>
> Em 18/08/2020 16:40, Lucas Willian Bocchi escreveu:
> > N?o tem pessoal.
> > J? falei com eles v?rias vezes numa boa e nunca consegui resolver. Tenho
> 6
> > ou 7 provedores com o mesmo problema. Alguns nem tem TR?NSITO com a
> Level3
> > mas eles acabam prendendo a rota mesmo assim. N?s vamos enviar uma
> > notifica??o extra-judicial em nome de todos esses provedores. Vemos que
> ? a
> > ?nica forma de resolver.
> >
> > Em ter., 18 de ago. de 2020 ?s 16:32, Alexandre Aleixo | Opticalhost <
> > alexandre at opticalhost.com.br> escreveu:
> >
> >> N?o tem ningu?m aqui da L3 que possa ver isso?
> >>
> >> Parece algo t?o simples, como uma configura??o de "hold time" do
> >> keepalive em menor tempo, pra que a sess?o seja derrubada mais
> >> rapidamente...
> >>
> >> Alexandre Aleixo
> >>
> >>
> >>
> >>
> >> Em ter., 18 de ago. de 2020 ?s 15:50, Alysson Jose da Silva <
> >> alyssonjose at gmail.com> escreveu:
> >>
> >>> Aconteceu aqui tamb?m, mas no AS 3549
> >>>
> >>> triste....
> >>>
> >>> Em 18/08/2020 15:29, Jo?o Butzke escreveu:
> >>>> Acontece aqui no sul tambem, n?o ? privil?gio do norte rsrsrsrs
> >>>>
> >>>> Att,
> >>>>
> >>>> Em 17/08/2020 17:35, Vinicius Gruske Dorneles escreveu:
> >>>>> Estou com um cliente do Norte do pa?s com rota presa no AS3556 nesse
> >>>>> exato momento. Estou tendo que anunciar o an?ncio /24, pois o /23
> pela
> >>>>> rota presa tem AS-PATH menor que o da outra operadora. Acabei de
> ligar
> >>>>> para o suporte da Century Link, e a menina me falou que um Engenheiro
> >>>>> iria me retornar. Esperar para ver...
> >>>>>
> >>>>> Tenho um outro cliente que fecha sess?o com o AS3549 em Porto Alegre,
> >>>>> que, igualmente ao relato do Vagner, n?o tem problemas com rota
> presa.
> >>>>>
> >>>>> Mas eu percebi que esses problemas acontecem com ASNs que est?o mais
> >>>>> pro norte do pa?s. O que faria sentido se o problema for em um
> >>>>> roteador no Rio de Janeiro.
> >>>>>
> >>>>> Em seg., 17 de ago. de 2020 ?s 16:40, vagner silva sousa
> >>>>> <vagnerss2011 at gmail.com> escreveu:
> >>>>>> Na ?poca me relataram que o problema era porque estavam migrando o
> >>>>>> AS3549
> >>>>>> para o AS3356 e tinha um roteador no Rio de Janeiro que estava
> >>>>>> desatualizado e estava prendendo os prefixos.
> >>>>>>
> >>>>>> Em seg., 17 de ago. de 2020 ?s 16:09, Vagner Felipe Becker <
> >>>>>> vagner at nexsul.com.br> escreveu:
> >>>>>>
> >>>>>>> Rota presa?! Ser? que a L3 come?ou a adotar Mikrotik no core?!
> >>>>>>>
> >>>>>>> kkkk, brincadeiras a parte, tenho sess?o fechada com eles no AS3549
> >> em
> >>>>>>> Porto Alegre e nunca me aconteceu isso. Vou subir um peer nos
> >> p?oximos
> >>>>>>> dias por SP via bilateral no IX no AS3356, vou testar se o problema
> >>>>>>> ocorre e posto pra vcs.
> >>>>>>>
> >>>>>>> Att,
> >>>>>>>
> >>>>>>> Vagner Felipe Becker
> >>>>>>>
> >>>>>>> Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
> >>>>>>>> Eu ja reclamei com o time de engenharia deles e nao tive retorno.
> >>>>>>>> Tenho
> >>>>>>>> esse problema a meses.
> >>>>>>>> Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
> >>>>>>>>
> >>>>>>>> Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <
> >>>>>>> robson at netnew.com.br>
> >>>>>>>> escreveu:
> >>>>>>>>
> >>>>>>>>> Boa tarde
> >>>>>>>>>
> >>>>>>>>> Peguei 2 casos em lugares diferentes com o mesmo problema
> >>>>>>>>>
> >>>>>>>>> Em um, retiramos os an?ncios da sess?o com eles e o
> >>>>>>>>> outro caso foi um rompimento que derrubou a sess?o
> >>>>>>>>>
> >>>>>>>>> ambos as rotas ficaram "presas" nas consultas pelos looking glass
> >>>>>>>>> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico
> >> por
> >>>>>>> outra
> >>>>>>>>> operadora
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Att.
> >>>>>>>>>
> >>>>>>>>> Robson F. Ramaldes
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -----Mensagem original-----
> >>>>>>>>> De: gter <gter-bounces at eng.registro.br> Em nome de Charles
> >> Barreto
> >>>>>>> Macedo
> >>>>>>>>> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
> >>>>>>>>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> >>>>>>>>> gter at eng.registro.br>
> >>>>>>>>> Assunto: Re: [GTER] Rota presa AS3356 Level3
> >>>>>>>>>
> >>>>>>>>> Bom Dia,
> >>>>>>>>>
> >>>>>>>>> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais
> >> de 6
> >>>>>>> Horas
> >>>>>>>>> para baixar os an?ncios..
> >>>>>>>>>
> >>>>>>>>> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <
> >>>>>>> paivgabriel at gmail.com>
> >>>>>>>>> escreveu:
> >>>>>>>>>
> >>>>>>>>>> N?s paramos de anunciar para nossos upstreams um /21 inteiro as
> >>>>>>>>>> 6 da
> >>>>>>>>>> manh?, porem este ASN ainda mantem o /21 na sua tabela de
> >>>>>>>>>> roteamento e
> >>>>>>>>>> espalhando este bloco indevidamente, mesmo n?o estando sendo
> >>>>>>>>>> anunciado
> >>>>>>>>>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
> >>>>>>>>>> --
> >>>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
> >>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Atenciosamente,
> >>>>>>>>>
> >>>>>>>>> Charles Barreto
> >>>>>>>>> Zoom Telecomunica??es
> >>>>>>>>> (44) 31112-2477
> >>>>>>>>>
> >>>>>>>>> www.zoominternet.com.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
> >>>>>>> --
> >>>>>>>
> >>>>>>> *Vagner Felipe Becker*
> >>>>>>>
> >>>>>>> Nexsul Conectividade
> >>>>>>>
> >>>>>>>
> >>>>>>> Tel: +55(51)3712-7600 | +55(51)99754-4730
> >>>>>>>
> >>>>>>> Rod. RSC 453 KM 39,5, 609 - 101, CEP 95880-000
> >>>>>>>
> >>>>>>> Rio Grande do Sul, RS - Brasil
> >>>>>>>
> >>>>>>>
> >>>>>>> Nexsul <https://www.nexsul.com.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
> >>
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From roosveltdavid at hotmail.com  Tue Aug 18 19:34:14 2020
From: roosveltdavid at hotmail.com (Roosvelt David)
Date: Tue, 18 Aug 2020 22:34:14 +0000
Subject: [GTER] RES:  RES: Rota presa AS3356 Level3
In-Reply-To: <9f408064-a062-8f07-c180-6e6a9d132e5f@gomais.com.br>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
 <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
 <95b7c0ba-0319-1941-c361-21aa904567c9@naxi.com.br>
 <df36b6c6-0b81-4b5d-1e32-c8cef40d2b26@gmail.com>
 <CAO4k366S7kcT7Lfg11H9H8a+TfTusfUtiQjjtgzcMmMtKdkSRg@mail.gmail.com>
 <CA+m52=fnMt+qkK2uvJD5prVwb7SSz-kge5_zPZu0NXoKxkGb7g@mail.gmail.com>,
 <9f408064-a062-8f07-c180-6e6a9d132e5f@gomais.com.br>
Message-ID: <DM6PR01MB4938A5CD018FAA165DC1785FBB5C0@DM6PR01MB4938.prod.exchangelabs.com>

Forte ataque uma pinoia. ? safadeza mesmo.

N?o ? desculpa pra prender um an?ncio por 6h ou mais na tabela. Isso n?o ? de hoje. Eu j? tenho esse problema com 3549/3356 h? anos.

J? tive problemas de ficar com a opera??o fora e os an?ncios pela L3/CTL continuavam firmes e fortes depois de horas da borda estando Desligada.

Outras vezes tomando ataque DDoS anunciei tudo em cima da mitiga??o, mas ela n?o fazia efeito por conta dos /24 pela  L3 estarem presos e eu ter de ligar no suporte pedindo pelo amor de Deus pra limparem as rotas pra poder usar a mitiga??o do DDoS.

Todas as vezes que escalonei pra engenharia sempre mencionaram uma dita caixa dentro da hierarquia dos Routing reflectors do ASN3549 no RJO que estava desatualizada que gerava esse comportamento de ?rota presa? (pelo visto ainda continua)

Como 3549 e 3356 s?o ASN?s confederados, a ?rota presa? no 3549 fica propagada no 3356 at? algu?m ir l? no dito roteador do 3549 e for?ar o refresh manualmente.

Segundo o que a Engenharia me jurava de p? junto que esse comportamento era restrito as sess?es fechadas no ASN 3549. Sess?es que j? eram fechadas no AS3356 n?o tinham esse problema.

Por?m, algumas  de vezes j? peguei o comportamento ocorrendo tamb?m em sess?es fechadas no 3356. Especialmente no Nordeste e Centro-Oeste.

Hoje para contornar esse comportamento, sempre que eu pego algum cen?rio que envolva L3/CTL sempre coloco alguns prepends nos an?ncios que saem por ela para que em caso de emerg?ncia eu consiga manipular alguma coisa, pois ? quase certo que sempre vai prender alguma coisa na L3/CTL.




De: contato at gomaicom.br<mailto:contato at gomaicom.br>
Enviado:ter?a-feira, 18 de agosto de 2020 16:52
Para: gter at eng.registro.br<mailto:gter at eng.registro.br>
Assunto: Re: [GTER] RES: Rota presa AS3356 Level3

eles est?o sobre forte ataques por isso est? esse caos.
estou com dois provedores usa Level3 direto
somados est?o recebendo 1tera de ataque

Em 18/08/2020 16:40, Lucas Willian Bocchi escreveu:
> N?o tem pessoal.
> J? falei com eles v?rias vezes numa boa e nunca consegui resolver. Tenho 6
> ou 7 provedores com o mesmo problema. Alguns nem tem TR?NSITO com a Level3
> mas eles acabam prendendo a rota mesmo assim. N?s vamos enviar uma
> notifica??o extra-judicial em nome de todos esses provedores. Vemos que ? a
> ?nica forma de resolver.
>
> Em ter., 18 de ago. de 2020 ?s 16:32, Alexandre Aleixo | Opticalhost <
> alexandre at opticalhost.com.br> escreveu:
>
>> N?o tem ningu?m aqui da L3 que possa ver isso?
>>
>> Parece algo t?o simples, como uma configura??o de "hold time" do
>> keepalive em menor tempo, pra que a sess?o seja derrubada mais
>> rapidamente...
>>
>> Alexandre Aleixo
>>
>>
>>
>>
>> Em ter., 18 de ago. de 2020 ?s 15:50, Alysson Jose da Silva <
>> alyssonjose at gmail.com> escreveu:
>>
>>> Aconteceu aqui tamb?m, mas no AS 3549
>>>
>>> triste....
>>>
>>> Em 18/08/2020 15:29, Jo?o Butzke escreveu:
>>>> Acontece aqui no sul tambem, n?o ? privil?gio do norte rsrsrsrs
>>>>
>>>> Att,
>>>>
>>>> Em 17/08/2020 17:35, Vinicius Gruske Dorneles escreveu:
>>>>> Estou com um cliente do Norte do pa?s com rota presa no AS3556 nesse
>>>>> exato momento. Estou tendo que anunciar o an?ncio /24, pois o /23 pela
>>>>> rota presa tem AS-PATH menor que o da outra operadora. Acabei de ligar
>>>>> para o suporte da Century Link, e a menina me falou que um Engenheiro
>>>>> iria me retornar. Esperar para ver...
>>>>>
>>>>> Tenho um outro cliente que fecha sess?o com o AS3549 em Porto Alegre,
>>>>> que, igualmente ao relato do Vagner, n?o tem problemas com rota presa.
>>>>>
>>>>> Mas eu percebi que esses problemas acontecem com ASNs que est?o mais
>>>>> pro norte do pa?s. O que faria sentido se o problema for em um
>>>>> roteador no Rio de Janeiro.
>>>>>
>>>>> Em seg., 17 de ago. de 2020 ?s 16:40, vagner silva sousa
>>>>> <vagnerss2011 at gmail.com> escreveu:
>>>>>> Na ?poca me relataram que o problema era porque estavam migrando o
>>>>>> AS3549
>>>>>> para o AS3356 e tinha um roteador no Rio de Janeiro que estava
>>>>>> desatualizado e estava prendendo os prefixos.
>>>>>>
>>>>>> Em seg., 17 de ago. de 2020 ?s 16:09, Vagner Felipe Becker <
>>>>>> vagner at nexsul.com.br> escreveu:
>>>>>>
>>>>>>> Rota presa?! Ser? que a L3 come?ou a adotar Mikrotik no core?!
>>>>>>>
>>>>>>> kkkk, brincadeiras a parte, tenho sess?o fechada com eles no AS3549
>> em
>>>>>>> Porto Alegre e nunca me aconteceu isso. Vou subir um peer nos
>> p?oximos
>>>>>>> dias por SP via bilateral no IX no AS3356, vou testar se o problema
>>>>>>> ocorre e posto pra vcs.
>>>>>>>
>>>>>>> Att,
>>>>>>>
>>>>>>> Vagner Felipe Becker
>>>>>>>
>>>>>>> Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
>>>>>>>> Eu ja reclamei com o time de engenharia deles e nao tive retorno.
>>>>>>>> Tenho
>>>>>>>> esse problema a meses.
>>>>>>>> Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
>>>>>>>>
>>>>>>>> Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <
>>>>>>> robson at netnew.com.br>
>>>>>>>> escreveu:
>>>>>>>>
>>>>>>>>> Boa tarde
>>>>>>>>>
>>>>>>>>> Peguei 2 casos em lugares diferentes com o mesmo problema
>>>>>>>>>
>>>>>>>>> Em um, retiramos os an?ncios da sess?o com eles e o
>>>>>>>>> outro caso foi um rompimento que derrubou a sess?o
>>>>>>>>>
>>>>>>>>> ambos as rotas ficaram "presas" nas consultas pelos looking glass
>>>>>>>>> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico
>> por
>>>>>>> outra
>>>>>>>>> operadora
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Att.
>>>>>>>>>
>>>>>>>>> Robson F. Ramaldes
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Mensagem original-----
>>>>>>>>> De: gter <gter-bounces at eng.registro.br> Em nome de Charles
>> Barreto
>>>>>>> Macedo
>>>>>>>>> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
>>>>>>>>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
>>>>>>>>> gter at eng.registro.br>
>>>>>>>>> Assunto: Re: [GTER] Rota presa AS3356 Level3
>>>>>>>>>
>>>>>>>>> Bom Dia,
>>>>>>>>>
>>>>>>>>> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais
>> de 6
>>>>>>> Horas
>>>>>>>>> para baixar os an?ncios..
>>>>>>>>>
>>>>>>>>> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <
>>>>>>> paivgabriel at gmail.com>
>>>>>>>>> escreveu:
>>>>>>>>>
>>>>>>>>>> N?s paramos de anunciar para nossos upstreams um /21 inteiro as
>>>>>>>>>> 6 da
>>>>>>>>>> manh?, porem este ASN ainda mantem o /21 na sua tabela de
>>>>>>>>>> roteamento e
>>>>>>>>>> espalhando este bloco indevidamente, mesmo n?o estando sendo
>>>>>>>>>> anunciado
>>>>>>>>>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
>>>>>>>>>> --
>>>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Atenciosamente,
>>>>>>>>>
>>>>>>>>> Charles Barreto
>>>>>>>>> Zoom Telecomunica??es
>>>>>>>>> (44) 31112-2477
>>>>>>>>>
>>>>>>>>> www.zoominternet.com.br<http://www.zoominternet.com.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
>>>>>>> --
>>>>>>>
>>>>>>> *Vagner Felipe Becker*
>>>>>>>
>>>>>>> Nexsul Conectividade
>>>>>>>
>>>>>>>
>>>>>>> Tel: +55(51)3712-7600 | +55(51)99754-4730
>>>>>>>
>>>>>>> Rod. RSC 453 KM 39,5, 609 - 101, CEP 95880-000
>>>>>>>
>>>>>>> Rio Grande do Sul, RS - Brasil
>>>>>>>
>>>>>>>
>>>>>>> Nexsul <https://www.nexsul.com.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
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
--
gter list    https://eng.registro.br/mailman/listinfo/gter


From patara at registro.br  Wed Aug 19 15:33:12 2020
From: patara at registro.br (Ricardo Patara)
Date: Wed, 19 Aug 2020 15:33:12 -0300
Subject: [GTER] Reservas de IPv4 chegam ao fim
Message-ID: <842fe6a8-f9fb-0823-7af3-63540597983f@registro.br>


O estoque de endere?os IPv4 para a regi?o da Am?rica Latina e o Caribe
esgotou-se na data de hoje (19/8/2020).

A fase da pol?tica de aloca??o controlada de endere?os IPv4 durante o
per?odo de iminente esgotamento [1] encerrou-se hoje. Ela garantia,
somente aos novos entrantes no mercado de Internet, que eles pudessem
receber ao menos uma pequena quantidade de endere?os.

No per?odo de vig?ncia desta pol?tica, 5.6 milh?es de endere?os IPv4
foram alocados, sendo mais de 4 milh?es somente no Brasil.

Seguindo o previsto nesta pol?tica, todas essas organiza??es tamb?m
receberam aloca??es de blocos IPv6. Com isso, mais de 96% das
organiza??es com ASN e IPv4 tamb?m j? possuem aloca??es de endere?os
IPv6. Hoje o tr?fego IPv6 no Brasil est? em franca expans?o e j?
representa mais de 1/3 do volume total.

A partir de agora, ?s organiza??es que venham a solicitar
justificadamente a necessidade de endere?os IPv4, e que ainda n?o
contaram com aloca??o desse recurso, ser? dada a op??o de permanecer
em uma fila de pedidos aprovados. Estes pedidos ser?o eventualmente
atendidos de acordo com os recursos que venham a se tornar dispon?veis
ap?s processos de recupera??o e devolu??o.


[1] https://www.lacnic.net/1077/3/lacnic/fases-de-esgotamento-do-ipv4


From elizandro at pachecotecnologia.net  Wed Aug 19 17:30:21 2020
From: elizandro at pachecotecnologia.net (=?utf-8?q?Elizandro=20Pacheco=20=5b=20NextHop=20Solutions=20=c2=ae=20=5d?=)
Date: Wed, 19 Aug 2020 20:30:21 +0000
Subject: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24
In-Reply-To: <842fe6a8-f9fb-0823-7af3-63540597983f@registro.br>
References: <842fe6a8-f9fb-0823-7af3-63540597983f@registro.br>
Message-ID: <em56d97541-8505-44f8-8aa9-792fe57bdccd@elliot>

Prezados, algu?m na lista gerencia o ASN? Fizeram hijack mais espec?fico 
de um prefixo meu e ? um dos meus prefixos do CGNAT.

N?o sei o que ? pior, o cara que faz isso ou o upstream que aceita!


Tor?o pelo RPKI, porque est? dif?cil.

Se tiver, favor me chamar no privado ou pelo 51 998718111



Elizandro Pacheco
NextHop Solutions


From alyssonjose at gmail.com  Wed Aug 19 19:13:02 2020
From: alyssonjose at gmail.com (Alysson Jose Silva)
Date: Wed, 19 Aug 2020 19:13:02 -0300
Subject: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24
In-Reply-To: <em56d97541-8505-44f8-8aa9-792fe57bdccd@elliot>
References: <842fe6a8-f9fb-0823-7af3-63540597983f@registro.br>
 <em56d97541-8505-44f8-8aa9-792fe57bdccd@elliot>
Message-ID: <CABdDRjv6db6XkdtF-Q=sTcDoB4QNCWNBGqUxPW40p1qb5kfx+Q@mail.gmail.com>

Se nao conseguir contato com o asn diretamente, tenta ver com os upstreams
que aceitaram pra ver se filtram isso

Em qua, 19 de ago de 2020 17:30, Elizandro Pacheco [ NextHop Solutions ? ] <
elizandro at pachecotecnologia.net> escreveu:

> Prezados, algu?m na lista gerencia o ASN? Fizeram hijack mais espec?fico
> de um prefixo meu e ? um dos meus prefixos do CGNAT.
>
> N?o sei o que ? pior, o cara que faz isso ou o upstream que aceita!
>
>
> Tor?o pelo RPKI, porque est? dif?cil.
>
> Se tiver, favor me chamar no privado ou pelo 51 998718111
>
>
>
> Elizandro Pacheco
> NextHop Solutions
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From alexandre at opticalhost.com.br  Wed Aug 19 19:32:39 2020
From: alexandre at opticalhost.com.br (Alexandre Aleixo | Opticalhost)
Date: Wed, 19 Aug 2020 19:32:39 -0300
Subject: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24
In-Reply-To: <em56d97541-8505-44f8-8aa9-792fe57bdccd@elliot>
References: <842fe6a8-f9fb-0823-7af3-63540597983f@registro.br>
 <em56d97541-8505-44f8-8aa9-792fe57bdccd@elliot>
Message-ID: <CAO4k364hZz1GL0BpSw+7oGLbEu0wmv8D+rWpXg7fP3TLMFd3Sw@mail.gmail.com>

N?o sei se j? tem essas infos, mas a? vai minha contribui??o:

Dados do AS:
https://everestridge.com.br/
Tel.: (11) 3181.4008
MARCIO VIDAL
marcio.vidal at everestridge.com.br

Alexandre Aleixo



Em qua., 19 de ago. de 2020 ?s 17:30, Elizandro Pacheco [ NextHop Solutions
? ] <elizandro at pachecotecnologia.net> escreveu:

> Prezados, algu?m na lista gerencia o ASN? Fizeram hijack mais espec?fico
> de um prefixo meu e ? um dos meus prefixos do CGNAT.
>
> N?o sei o que ? pior, o cara que faz isso ou o upstream que aceita!
>
>
> Tor?o pelo RPKI, porque est? dif?cil.
>
> Se tiver, favor me chamar no privado ou pelo 51 998718111
>
>
>
> Elizandro Pacheco
> NextHop Solutions
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From elizandro at pachecotecnologia.net  Wed Aug 19 21:45:14 2020
From: elizandro at pachecotecnologia.net (=?utf-8?q?Elizandro=20Pacheco=20=5b=20NextHop=20Solutions=20=c2=ae=20=5d?=)
Date: Thu, 20 Aug 2020 00:45:14 +0000
Subject: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24
In-Reply-To: <CAO4k364hZz1GL0BpSw+7oGLbEu0wmv8D+rWpXg7fP3TLMFd3Sw@mail.gmail.com>
References: <842fe6a8-f9fb-0823-7af3-63540597983f@registro.br>
 <em56d97541-8505-44f8-8aa9-792fe57bdccd@elliot>
 <CAO4k364hZz1GL0BpSw+7oGLbEu0wmv8D+rWpXg7fP3TLMFd3Sw@mail.gmail.com>
Message-ID: <emc129ed55-2ce4-46f4-ae7e-cdee64808809@elliot>

Obrigado pessoal!

O que aconteceu ? que esse ASN presta servi?os para um de meus 
upstreams. E eles tem uma ferramenta anti DDOS, certamente houve um 
falso positivo, j? que esse prefixo tem quase 6 mil assinantes atr?s 
dele no CGNAT, ent?o o consumo ? realmente alto.

Acredito que a ferramenta "anti ddos" tomou uma a??o errada e propagou 
pra tabela global o prefixo ao inv?s de tomar uma a??o de bloqueio.

Erro atr?s de erro. Mas conseguimos contato via telefone e foi 
prontamente atendido.

Agora ? s? criar uma f?rmula m?gica pra explicar pros clientes.

Agrade?o a todas mensagens de ajuda no privado. Muito obrigado mesmo!


Forte abra?o,

Elizandro Pacheco

------ Mensagem original ------
De: "Alexandre Aleixo | Opticalhost" <alexandre at opticalhost.com.br>
Para: "Grupo de Trabalho de Engenharia e Operacao de Redes" 
<gter at eng.registro.br>
Enviado(s): 19/08/2020 19:32:39
Assunto: Re: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24

>N?o sei se j? tem essas infos, mas a? vai minha contribui??o:
>
>Dados do AS:
>https://everestridge.com.br/
>Tel.: (11) 3181.4008
>MARCIO VIDAL
>marcio.vidal at everestridge.com.br
>
>Alexandre Aleixo
>
>
>
>Em qua., 19 de ago. de 2020 ?s 17:30, Elizandro Pacheco [ NextHop Solutions
>? ] <elizandro at pachecotecnologia.net> escreveu:
>
>>  Prezados, algu?m na lista gerencia o ASN? Fizeram hijack mais espec?fico
>>  de um prefixo meu e ? um dos meus prefixos do CGNAT.
>>
>>  N?o sei o que ? pior, o cara que faz isso ou o upstream que aceita!
>>
>>
>>  Tor?o pelo RPKI, porque est? dif?cil.
>>
>>  Se tiver, favor me chamar no privado ou pelo 51 998718111
>>
>>
>>
>>  Elizandro Pacheco
>>  NextHop Solutions
>>
>>  --
>>  gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>--
>gter list    https://eng.registro.br/mailman/listinfo/gter


From bruno at openline.com.br  Wed Aug 19 21:53:09 2020
From: bruno at openline.com.br (Bruno Cabral)
Date: Thu, 20 Aug 2020 00:53:09 +0000
Subject: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24
In-Reply-To: <emc129ed55-2ce4-46f4-ae7e-cdee64808809@elliot>
References: <842fe6a8-f9fb-0823-7af3-63540597983f@registro.br>
 <em56d97541-8505-44f8-8aa9-792fe57bdccd@elliot>
 <CAO4k364hZz1GL0BpSw+7oGLbEu0wmv8D+rWpXg7fP3TLMFd3Sw@mail.gmail.com>,
 <emc129ed55-2ce4-46f4-ae7e-cdee64808809@elliot>
Message-ID: <CP2PR80MB36352244DB89CC4886D812C3F55A0@CP2PR80MB3635.lamprd80.prod.outlook.com>

A desculpa padrao que sempre escuto ? "rompimento duplo do anel de fibra"...


________________________________

Agora ? s? criar uma f?rmula m?gica pra explicar pros clientes.

Agrade?o a todas mensagens de ajuda no privado. Muito obrigado mesmo!


Forte abra?o,

Elizandro Pacheco


From elizandro at pachecotecnologia.net  Thu Aug 20 08:51:16 2020
From: elizandro at pachecotecnologia.net (Elizandro Pacheco [ Pacheco Tecnologia ])
Date: Thu, 20 Aug 2020 08:51:16 -0300
Subject: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24
In-Reply-To: <CP2PR80MB36352244DB89CC4886D812C3F55A0@CP2PR80MB3635.lamprd80.prod.outlook.com>
References: <842fe6a8-f9fb-0823-7af3-63540597983f@registro.br>
 <em56d97541-8505-44f8-8aa9-792fe57bdccd@elliot>
 <CAO4k364hZz1GL0BpSw+7oGLbEu0wmv8D+rWpXg7fP3TLMFd3Sw@mail.gmail.com>
 <emc129ed55-2ce4-46f4-ae7e-cdee64808809@elliot>
 <CP2PR80MB36352244DB89CC4886D812C3F55A0@CP2PR80MB3635.lamprd80.prod.outlook.com>
Message-ID: <CAOCsn+cxeC1cYBNmXcVXwY9X=3qBf3Y6x+1zCsVzsQWLs89LfQ@mail.gmail.com>

E pra variar, basta dar uma consultada no LG da Algar neste exato momento
pra ver que esses caras vazaram o prefixo DE NOVO!

? mole?

Elizandro Pacheco

Em qua, 19 de ago de 2020 21:53, Bruno Cabral <bruno at openline.com.br>
escreveu:

> A desculpa padrao que sempre escuto ? "rompimento duplo do anel de
> fibra"...
>
>
> ------------------------------
>
> Agora ? s? criar uma f?rmula m?gica pra explicar pros clientes.
>
> Agrade?o a todas mensagens de ajuda no privado. Muito obrigado mesmo!
>
>
> Forte abra?o,
>
> Elizandro Pacheco
>
>

From talesrodarte at gmail.com  Thu Aug 20 09:18:32 2020
From: talesrodarte at gmail.com (Tales Rodarte)
Date: Thu, 20 Aug 2020 09:18:32 -0300
Subject: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24
In-Reply-To: <CAOCsn+cxeC1cYBNmXcVXwY9X=3qBf3Y6x+1zCsVzsQWLs89LfQ@mail.gmail.com>
References: <842fe6a8-f9fb-0823-7af3-63540597983f@registro.br>
 <em56d97541-8505-44f8-8aa9-792fe57bdccd@elliot>
 <CAO4k364hZz1GL0BpSw+7oGLbEu0wmv8D+rWpXg7fP3TLMFd3Sw@mail.gmail.com>
 <emc129ed55-2ce4-46f4-ae7e-cdee64808809@elliot>
 <CP2PR80MB36352244DB89CC4886D812C3F55A0@CP2PR80MB3635.lamprd80.prod.outlook.com>
 <CAOCsn+cxeC1cYBNmXcVXwY9X=3qBf3Y6x+1zCsVzsQWLs89LfQ@mail.gmail.com>
Message-ID: <180ae47b-945b-a31c-a954-54d53b1a5cb9@gmail.com>

Aproveitando a treta, digo thread.

Por exemplo:

Cliente anuncia um prefixo menos espec?fico. Este prefixo ? atacado.
O tr?fego malicioso passa pelo upstream no qual o prefixo est? 
anunciado, realiza a filtragem, marca com no-export-all e encaminhar 
para plataforma de mitiga??o.

Entendo que se o upstream fornece o servi?o de filtragem, ele for?a o 
anuncio mais espec?fico para puxar o maior tr?fego poss?vel.

A pergunta ?:
Neste cen?rio ? realmente necess?rio rescrever o as-path (considerando 
que o sistema de mitiga??o origina o prefixo) e/ou anunciar sempre mais 
espec?fico ?
S? de reescrever o as-path com o asn local j? quebra v?rios mecanismos 
de valida??o.

Parece que fazer algo assim cria espa?o para mais problemas do que solu??o.


--

Tales Costa

Em 20/08/2020 08:51, Elizandro Pacheco [ Pacheco Tecnologia ] escreveu:
> E pra variar, basta dar uma consultada no LG da Algar neste exato momento
> pra ver que esses caras vazaram o prefixo DE NOVO!
>
> ? mole?
>
> Elizandro Pacheco
>
> Em qua, 19 de ago de 2020 21:53, Bruno Cabral <bruno at openline.com.br>
> escreveu:
>
>> A desculpa padrao que sempre escuto ? "rompimento duplo do anel de
>> fibra"...
>>
>>
>> ------------------------------
>>
>> Agora ? s? criar uma f?rmula m?gica pra explicar pros clientes.
>>
>> Agrade?o a todas mensagens de ajuda no privado. Muito obrigado mesmo!
>>
>>
>> Forte abra?o,
>>
>> Elizandro Pacheco
>>
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter



From alexandre at opticalhost.com.br  Thu Aug 20 12:51:59 2020
From: alexandre at opticalhost.com.br (Alexandre Aleixo | Opticalhost)
Date: Thu, 20 Aug 2020 12:51:59 -0300
Subject: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24
In-Reply-To: <180ae47b-945b-a31c-a954-54d53b1a5cb9@gmail.com>
References: <842fe6a8-f9fb-0823-7af3-63540597983f@registro.br>
 <em56d97541-8505-44f8-8aa9-792fe57bdccd@elliot>
 <CAO4k364hZz1GL0BpSw+7oGLbEu0wmv8D+rWpXg7fP3TLMFd3Sw@mail.gmail.com>
 <emc129ed55-2ce4-46f4-ae7e-cdee64808809@elliot>
 <CP2PR80MB36352244DB89CC4886D812C3F55A0@CP2PR80MB3635.lamprd80.prod.outlook.com>
 <CAOCsn+cxeC1cYBNmXcVXwY9X=3qBf3Y6x+1zCsVzsQWLs89LfQ@mail.gmail.com>
 <180ae47b-945b-a31c-a954-54d53b1a5cb9@gmail.com>
Message-ID: <CAO4k365+bA1DGfaGhfgQx-GCG+nC=cOusvAm36NpDtH46MkGpA@mail.gmail.com>

O que n?o d? pra entender ? como grandes operadoras ainda n?o fazem
valida??o RPKI... Ou at? fazem, pra "ficar bonito" no LG... Mas n?o usam a
valida??o com grande peso na sele??o de rotas....

Alexandre Aleixo




Em qui., 20 de ago. de 2020 ?s 09:18, Tales Rodarte <talesrodarte at gmail.com>
escreveu:

> Aproveitando a treta, digo thread.
>
> Por exemplo:
>
> Cliente anuncia um prefixo menos espec?fico. Este prefixo ? atacado.
> O tr?fego malicioso passa pelo upstream no qual o prefixo est?
> anunciado, realiza a filtragem, marca com no-export-all e encaminhar
> para plataforma de mitiga??o.
>
> Entendo que se o upstream fornece o servi?o de filtragem, ele for?a o
> anuncio mais espec?fico para puxar o maior tr?fego poss?vel.
>
> A pergunta ?:
> Neste cen?rio ? realmente necess?rio rescrever o as-path (considerando
> que o sistema de mitiga??o origina o prefixo) e/ou anunciar sempre mais
> espec?fico ?
> S? de reescrever o as-path com o asn local j? quebra v?rios mecanismos
> de valida??o.
>
> Parece que fazer algo assim cria espa?o para mais problemas do que solu??o.
>
>
> --
>
> Tales Costa
>
> Em 20/08/2020 08:51, Elizandro Pacheco [ Pacheco Tecnologia ] escreveu:
> > E pra variar, basta dar uma consultada no LG da Algar neste exato momento
> > pra ver que esses caras vazaram o prefixo DE NOVO!
> >
> > ? mole?
> >
> > Elizandro Pacheco
> >
> > Em qua, 19 de ago de 2020 21:53, Bruno Cabral <bruno at openline.com.br>
> > escreveu:
> >
> >> A desculpa padrao que sempre escuto ? "rompimento duplo do anel de
> >> fibra"...
> >>
> >>
> >> ------------------------------
> >>
> >> Agora ? s? criar uma f?rmula m?gica pra explicar pros clientes.
> >>
> >> Agrade?o a todas mensagens de ajuda no privado. Muito obrigado mesmo!
> >>
> >>
> >> Forte abra?o,
> >>
> >> Elizandro Pacheco
> >>
> >>
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From mineiro at tca.com.br  Thu Aug 20 16:07:38 2020
From: mineiro at tca.com.br (Gabriel Mineiro)
Date: Thu, 20 Aug 2020 19:07:38 +0000
Subject: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24
Message-ID: <134210c0a6e04bbcaf937ab73077663d@tca.com.br>

Eles est?o reescrevendo o AS_PATH sem o seu AS como origem? Neste caso o RPKI realmente evitaria esse sequestro, por?m como ? um servi?o da empresa mitigadora, talvez eles n?o descartassem os prefixos originados por clientes deles propositalmente, para mostrar a "efic?cia" da produto.

Agora se eles deixaram o seu AS como origem e o tamanho do prefixo estava previsto na sua ROA, o RPKI validaria a rota e o "sequestro" continuaria.



Gabriel Mineiro

-----Mensagem original-----
De: gter <gter-bounces at eng.registro.br> Em nome de Elizandro Pacheco [ Pacheco Tecnologia ]
Enviada em: quinta-feira, 20 de agosto de 2020 08:51
Para: Bruno Cabral <bruno at openline.com.br>
Cc: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>
Assunto: Re: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24

E pra variar, basta dar uma consultada no LG da Algar neste exato momento pra ver que esses caras vazaram o prefixo DE NOVO!

? mole?

Elizandro Pacheco

Em qua, 19 de ago de 2020 21:53, Bruno Cabral <bruno at openline.com.br>
escreveu:

> A desculpa padrao que sempre escuto ? "rompimento duplo do anel de 
> fibra"...
>
>
> ------------------------------
>
> Agora ? s? criar uma f?rmula m?gica pra explicar pros clientes.
>
> Agrade?o a todas mensagens de ajuda no privado. Muito obrigado mesmo!
>
>
> Forte abra?o,
>
> Elizandro Pacheco
>
>
--
gter list    https://eng.registro.br/mailman/listinfo/gter

From andre.bolzan at fixfibra.com.br  Thu Aug 20 18:15:53 2020
From: andre.bolzan at fixfibra.com.br (Andre Bolzan)
Date: Thu, 20 Aug 2020 18:15:53 -0300
Subject: [GTER] RES: RES: Rota presa AS3356 Level3
In-Reply-To: <DM6PR01MB4938A5CD018FAA165DC1785FBB5C0@DM6PR01MB4938.prod.exchangelabs.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
 <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
 <95b7c0ba-0319-1941-c361-21aa904567c9@naxi.com.br>
 <df36b6c6-0b81-4b5d-1e32-c8cef40d2b26@gmail.com>
 <CAO4k366S7kcT7Lfg11H9H8a+TfTusfUtiQjjtgzcMmMtKdkSRg@mail.gmail.com>
 <CA+m52=fnMt+qkK2uvJD5prVwb7SSz-kge5_zPZu0NXoKxkGb7g@mail.gmail.com>
 <9f408064-a062-8f07-c180-6e6a9d132e5f@gomais.com.br>
 <DM6PR01MB4938A5CD018FAA165DC1785FBB5C0@DM6PR01MB4938.prod.exchangelabs.com>
Message-ID: <CAF1WzFHZ9Y5rfUVNhOqFSMdsR37ReMvziMykUtO0d_KL_MQqHQ@mail.gmail.com>

Agora fiquei com medo de fechar contrato com a LEVE3...

Empresa Tier1 com esse tipo de problema...

Sobre o tr?nsito a PTT-SP ainda ? recomend?vel? Os problemas se restringem
a sess?o IP ?

Em ter., 18 de ago. de 2020 ?s 19:34, Roosvelt David <
roosveltdavid at hotmail.com> escreveu:

> Forte ataque uma pinoia. ? safadeza mesmo.
>
> N?o ? desculpa pra prender um an?ncio por 6h ou mais na tabela. Isso n?o ?
> de hoje. Eu j? tenho esse problema com 3549/3356 h? anos.
>
> J? tive problemas de ficar com a opera??o fora e os an?ncios pela L3/CTL
> continuavam firmes e fortes depois de horas da borda estando Desligada.
>
> Outras vezes tomando ataque DDoS anunciei tudo em cima da mitiga??o, mas
> ela n?o fazia efeito por conta dos /24 pela  L3 estarem presos e eu ter de
> ligar no suporte pedindo pelo amor de Deus pra limparem as rotas pra poder
> usar a mitiga??o do DDoS.
>
> Todas as vezes que escalonei pra engenharia sempre mencionaram uma dita
> caixa dentro da hierarquia dos Routing reflectors do ASN3549 no RJO que
> estava desatualizada que gerava esse comportamento de ?rota presa? (pelo
> visto ainda continua)
>
> Como 3549 e 3356 s?o ASN?s confederados, a ?rota presa? no 3549 fica
> propagada no 3356 at? algu?m ir l? no dito roteador do 3549 e for?ar o
> refresh manualmente.
>
> Segundo o que a Engenharia me jurava de p? junto que esse comportamento
> era restrito as sess?es fechadas no ASN 3549. Sess?es que j? eram fechadas
> no AS3356 n?o tinham esse problema.
>
> Por?m, algumas  de vezes j? peguei o comportamento ocorrendo tamb?m em
> sess?es fechadas no 3356. Especialmente no Nordeste e Centro-Oeste.
>
> Hoje para contornar esse comportamento, sempre que eu pego algum cen?rio
> que envolva L3/CTL sempre coloco alguns prepends nos an?ncios que saem por
> ela para que em caso de emerg?ncia eu consiga manipular alguma coisa, pois
> ? quase certo que sempre vai prender alguma coisa na L3/CTL.
>
>
>
>
> De: contato at gomaicom.br<mailto:contato at gomaicom.br>
> Enviado:ter?a-feira, 18 de agosto de 2020 16:52
> Para: gter at eng.registro.br<mailto:gter at eng.registro.br>
> Assunto: Re: [GTER] RES: Rota presa AS3356 Level3
>
> eles est?o sobre forte ataques por isso est? esse caos.
> estou com dois provedores usa Level3 direto
> somados est?o recebendo 1tera de ataque
>
> Em 18/08/2020 16:40, Lucas Willian Bocchi escreveu:
> > N?o tem pessoal.
> > J? falei com eles v?rias vezes numa boa e nunca consegui resolver. Tenho
> 6
> > ou 7 provedores com o mesmo problema. Alguns nem tem TR?NSITO com a
> Level3
> > mas eles acabam prendendo a rota mesmo assim. N?s vamos enviar uma
> > notifica??o extra-judicial em nome de todos esses provedores. Vemos que
> ? a
> > ?nica forma de resolver.
> >
> > Em ter., 18 de ago. de 2020 ?s 16:32, Alexandre Aleixo | Opticalhost <
> > alexandre at opticalhost.com.br> escreveu:
> >
> >> N?o tem ningu?m aqui da L3 que possa ver isso?
> >>
> >> Parece algo t?o simples, como uma configura??o de "hold time" do
> >> keepalive em menor tempo, pra que a sess?o seja derrubada mais
> >> rapidamente...
> >>
> >> Alexandre Aleixo
> >>
> >>
> >>
> >>
> >> Em ter., 18 de ago. de 2020 ?s 15:50, Alysson Jose da Silva <
> >> alyssonjose at gmail.com> escreveu:
> >>
> >>> Aconteceu aqui tamb?m, mas no AS 3549
> >>>
> >>> triste....
> >>>
> >>> Em 18/08/2020 15:29, Jo?o Butzke escreveu:
> >>>> Acontece aqui no sul tambem, n?o ? privil?gio do norte rsrsrsrs
> >>>>
> >>>> Att,
> >>>>
> >>>> Em 17/08/2020 17:35, Vinicius Gruske Dorneles escreveu:
> >>>>> Estou com um cliente do Norte do pa?s com rota presa no AS3556 nesse
> >>>>> exato momento. Estou tendo que anunciar o an?ncio /24, pois o /23
> pela
> >>>>> rota presa tem AS-PATH menor que o da outra operadora. Acabei de
> ligar
> >>>>> para o suporte da Century Link, e a menina me falou que um Engenheiro
> >>>>> iria me retornar. Esperar para ver...
> >>>>>
> >>>>> Tenho um outro cliente que fecha sess?o com o AS3549 em Porto Alegre,
> >>>>> que, igualmente ao relato do Vagner, n?o tem problemas com rota
> presa.
> >>>>>
> >>>>> Mas eu percebi que esses problemas acontecem com ASNs que est?o mais
> >>>>> pro norte do pa?s. O que faria sentido se o problema for em um
> >>>>> roteador no Rio de Janeiro.
> >>>>>
> >>>>> Em seg., 17 de ago. de 2020 ?s 16:40, vagner silva sousa
> >>>>> <vagnerss2011 at gmail.com> escreveu:
> >>>>>> Na ?poca me relataram que o problema era porque estavam migrando o
> >>>>>> AS3549
> >>>>>> para o AS3356 e tinha um roteador no Rio de Janeiro que estava
> >>>>>> desatualizado e estava prendendo os prefixos.
> >>>>>>
> >>>>>> Em seg., 17 de ago. de 2020 ?s 16:09, Vagner Felipe Becker <
> >>>>>> vagner at nexsul.com.br> escreveu:
> >>>>>>
> >>>>>>> Rota presa?! Ser? que a L3 come?ou a adotar Mikrotik no core?!
> >>>>>>>
> >>>>>>> kkkk, brincadeiras a parte, tenho sess?o fechada com eles no AS3549
> >> em
> >>>>>>> Porto Alegre e nunca me aconteceu isso. Vou subir um peer nos
> >> p?oximos
> >>>>>>> dias por SP via bilateral no IX no AS3356, vou testar se o problema
> >>>>>>> ocorre e posto pra vcs.
> >>>>>>>
> >>>>>>> Att,
> >>>>>>>
> >>>>>>> Vagner Felipe Becker
> >>>>>>>
> >>>>>>> Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
> >>>>>>>> Eu ja reclamei com o time de engenharia deles e nao tive retorno.
> >>>>>>>> Tenho
> >>>>>>>> esse problema a meses.
> >>>>>>>> Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
> >>>>>>>>
> >>>>>>>> Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <
> >>>>>>> robson at netnew.com.br>
> >>>>>>>> escreveu:
> >>>>>>>>
> >>>>>>>>> Boa tarde
> >>>>>>>>>
> >>>>>>>>> Peguei 2 casos em lugares diferentes com o mesmo problema
> >>>>>>>>>
> >>>>>>>>> Em um, retiramos os an?ncios da sess?o com eles e o
> >>>>>>>>> outro caso foi um rompimento que derrubou a sess?o
> >>>>>>>>>
> >>>>>>>>> ambos as rotas ficaram "presas" nas consultas pelos looking glass
> >>>>>>>>> s? resolveu anunciando o mesmo bloco id?ntico ou mais especifico
> >> por
> >>>>>>> outra
> >>>>>>>>> operadora
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Att.
> >>>>>>>>>
> >>>>>>>>> Robson F. Ramaldes
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -----Mensagem original-----
> >>>>>>>>> De: gter <gter-bounces at eng.registro.br> Em nome de Charles
> >> Barreto
> >>>>>>> Macedo
> >>>>>>>>> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
> >>>>>>>>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> >>>>>>>>> gter at eng.registro.br>
> >>>>>>>>> Assunto: Re: [GTER] Rota presa AS3356 Level3
> >>>>>>>>>
> >>>>>>>>> Bom Dia,
> >>>>>>>>>
> >>>>>>>>> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais
> >> de 6
> >>>>>>> Horas
> >>>>>>>>> para baixar os an?ncios..
> >>>>>>>>>
> >>>>>>>>> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <
> >>>>>>> paivgabriel at gmail.com>
> >>>>>>>>> escreveu:
> >>>>>>>>>
> >>>>>>>>>> N?s paramos de anunciar para nossos upstreams um /21 inteiro as
> >>>>>>>>>> 6 da
> >>>>>>>>>> manh?, porem este ASN ainda mantem o /21 na sua tabela de
> >>>>>>>>>> roteamento e
> >>>>>>>>>> espalhando este bloco indevidamente, mesmo n?o estando sendo
> >>>>>>>>>> anunciado
> >>>>>>>>>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
> >>>>>>>>>> --
> >>>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
> >>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Atenciosamente,
> >>>>>>>>>
> >>>>>>>>> Charles Barreto
> >>>>>>>>> Zoom Telecomunica??es
> >>>>>>>>> (44) 31112-2477
> >>>>>>>>>
> >>>>>>>>> www.zoominternet.com.br<http://www.zoominternet.com.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
> >>>>>>> --
> >>>>>>>
> >>>>>>> *Vagner Felipe Becker*
> >>>>>>>
> >>>>>>> Nexsul Conectividade
> >>>>>>>
> >>>>>>>
> >>>>>>> Tel: +55(51)3712-7600 | +55(51)99754-4730
> >>>>>>>
> >>>>>>> Rod. RSC 453 KM 39,5, 609 - 101, CEP 95880-000
> >>>>>>>
> >>>>>>> Rio Grande do Sul, RS - Brasil
> >>>>>>>
> >>>>>>>
> >>>>>>> Nexsul <https://www.nexsul.com.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
> >>
> > --
> > 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
>


-- 

*Andr? Bolzan Saar*
*Andre.Bolzan at FIXFIBRA.com.br <Andre.Bolzan at FIXFIBRA.com.br>*
**55 11 98205-7742*

From elizandro at pachecotecnologia.net  Thu Aug 20 18:24:36 2020
From: elizandro at pachecotecnologia.net (=?utf-8?q?Elizandro=20Pacheco=20=5b=20NextHop=20Solutions=20=c2=ae=20=5d?=)
Date: Thu, 20 Aug 2020 21:24:36 +0000
Subject: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24
In-Reply-To: <134210c0a6e04bbcaf937ab73077663d@tca.com.br>
References: <134210c0a6e04bbcaf937ab73077663d@tca.com.br>
Message-ID: <emfa66d446-4f59-4a80-84bf-b7fa0c1f4494@elliot>



------ Mensagem original ------
De: "Gabriel Mineiro" <mineiro at tca.com.br>
Para: "Grupo de Trabalho de Engenharia e Operacao de Redes" 
<gter at eng.registro.br>
Enviado(s): 20/08/2020 16:07:38
Assunto: Re: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24

>Eles est?o reescrevendo o AS_PATH sem o seu AS como origem?

Exatamente, removeram hoje de novo. Vamos ver se acontece novamente.

Elizandro Pacheco


>Neste caso o RPKI realmente evitaria esse sequestro, por?m como ? um servi?o da empresa mitigadora, talvez eles n?o descartassem os prefixos originados por clientes deles propositalmente, para mostrar a "efic?cia" da produto.
>
>Agora se eles deixaram o seu AS como origem e o tamanho do prefixo estava previsto na sua ROA, o RPKI validaria a rota e o "sequestro" continuaria.
>
>
>
>Gabriel Mineiro
>
>-----Mensagem original-----
>De: gter <gter-bounces at eng.registro.br> Em nome de Elizandro Pacheco [ Pacheco Tecnologia ]
>Enviada em: quinta-feira, 20 de agosto de 2020 08:51
>Para: Bruno Cabral <bruno at openline.com.br>
>Cc: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>
>Assunto: Re: [GTER] AS267056 Hijack do Prefixo 138.99.161.0/24
>
>E pra variar, basta dar uma consultada no LG da Algar neste exato momento pra ver que esses caras vazaram o prefixo DE NOVO!
>
>? mole?
>
>Elizandro Pacheco
>
>Em qua, 19 de ago de 2020 21:53, Bruno Cabral <bruno at openline.com.br>
>escreveu:
>
>>  A desculpa padrao que sempre escuto ? "rompimento duplo do anel de
>>  fibra"...
>>
>>
>>  ------------------------------
>>
>>  Agora ? s? criar uma f?rmula m?gica pra explicar pros clientes.
>>
>>  Agrade?o a todas mensagens de ajuda no privado. Muito obrigado mesmo!
>>
>>
>>  Forte abra?o,
>>
>>  Elizandro Pacheco
>>
>>
>--
>gter list    https://eng.registro.br/mailman/listinfo/gter
>--
>gter list    https://eng.registro.br/mailman/listinfo/gter


From alexandre at opticalhost.com.br  Thu Aug 20 18:38:41 2020
From: alexandre at opticalhost.com.br (Alexandre Aleixo | Opticalhost)
Date: Thu, 20 Aug 2020 18:38:41 -0300
Subject: [GTER] RES: RES: Rota presa AS3356 Level3
In-Reply-To: <CAF1WzFHZ9Y5rfUVNhOqFSMdsR37ReMvziMykUtO0d_KL_MQqHQ@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
 <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
 <95b7c0ba-0319-1941-c361-21aa904567c9@naxi.com.br>
 <df36b6c6-0b81-4b5d-1e32-c8cef40d2b26@gmail.com>
 <CAO4k366S7kcT7Lfg11H9H8a+TfTusfUtiQjjtgzcMmMtKdkSRg@mail.gmail.com>
 <CA+m52=fnMt+qkK2uvJD5prVwb7SSz-kge5_zPZu0NXoKxkGb7g@mail.gmail.com>
 <9f408064-a062-8f07-c180-6e6a9d132e5f@gomais.com.br>
 <DM6PR01MB4938A5CD018FAA165DC1785FBB5C0@DM6PR01MB4938.prod.exchangelabs.com>
 <CAF1WzFHZ9Y5rfUVNhOqFSMdsR37ReMvziMykUtO0d_KL_MQqHQ@mail.gmail.com>
Message-ID: <CAO4k365XA5FYG5gqZTr1mkhbYpHJVKhjp41oCt9yFOcuAYEJOQ@mail.gmail.com>

 O problema n?o se restringe a quem fecha a sess?o diretamente com a L3,
mas tamb?m com quem fecha sess?o com alguma operadora que tenha sess?o com
eles e repasse o an?ncio indiretamente. E, como hoje em dia ? praticamente
imposs?vel fechar sess?o com alguma operadora que n?o tenha sess?o com a
L3..... A coisa complica.

Mas, "felizmente"... O problema "se resolve" anunciando o prefixo mais
espec?fico por outra operadora... Da? parece que atualiza a rota na tabela
da L3 (menos mal).


Alexandre Aleixo



Em qui., 20 de ago. de 2020 ?s 18:15, Andre Bolzan <
andre.bolzan at fixfibra.com.br> escreveu:

> Agora fiquei com medo de fechar contrato com a LEVE3...
>
> Empresa Tier1 com esse tipo de problema...
>
> Sobre o tr?nsito a PTT-SP ainda ? recomend?vel? Os problemas se restringem
> a sess?o IP ?
>
> Em ter., 18 de ago. de 2020 ?s 19:34, Roosvelt David <
> roosveltdavid at hotmail.com> escreveu:
>
> > Forte ataque uma pinoia. ? safadeza mesmo.
> >
> > N?o ? desculpa pra prender um an?ncio por 6h ou mais na tabela. Isso n?o
> ?
> > de hoje. Eu j? tenho esse problema com 3549/3356 h? anos.
> >
> > J? tive problemas de ficar com a opera??o fora e os an?ncios pela L3/CTL
> > continuavam firmes e fortes depois de horas da borda estando Desligada.
> >
> > Outras vezes tomando ataque DDoS anunciei tudo em cima da mitiga??o, mas
> > ela n?o fazia efeito por conta dos /24 pela  L3 estarem presos e eu ter
> de
> > ligar no suporte pedindo pelo amor de Deus pra limparem as rotas pra
> poder
> > usar a mitiga??o do DDoS.
> >
> > Todas as vezes que escalonei pra engenharia sempre mencionaram uma dita
> > caixa dentro da hierarquia dos Routing reflectors do ASN3549 no RJO que
> > estava desatualizada que gerava esse comportamento de ?rota presa? (pelo
> > visto ainda continua)
> >
> > Como 3549 e 3356 s?o ASN?s confederados, a ?rota presa? no 3549 fica
> > propagada no 3356 at? algu?m ir l? no dito roteador do 3549 e for?ar o
> > refresh manualmente.
> >
> > Segundo o que a Engenharia me jurava de p? junto que esse comportamento
> > era restrito as sess?es fechadas no ASN 3549. Sess?es que j? eram
> fechadas
> > no AS3356 n?o tinham esse problema.
> >
> > Por?m, algumas  de vezes j? peguei o comportamento ocorrendo tamb?m em
> > sess?es fechadas no 3356. Especialmente no Nordeste e Centro-Oeste.
> >
> > Hoje para contornar esse comportamento, sempre que eu pego algum cen?rio
> > que envolva L3/CTL sempre coloco alguns prepends nos an?ncios que saem
> por
> > ela para que em caso de emerg?ncia eu consiga manipular alguma coisa,
> pois
> > ? quase certo que sempre vai prender alguma coisa na L3/CTL.
> >
> >
> >
> >
> > De: contato at gomaicom.br<mailto:contato at gomaicom.br>
> > Enviado:ter?a-feira, 18 de agosto de 2020 16:52
> > Para: gter at eng.registro.br<mailto:gter at eng.registro.br>
> > Assunto: Re: [GTER] RES: Rota presa AS3356 Level3
> >
> > eles est?o sobre forte ataques por isso est? esse caos.
> > estou com dois provedores usa Level3 direto
> > somados est?o recebendo 1tera de ataque
> >
> > Em 18/08/2020 16:40, Lucas Willian Bocchi escreveu:
> > > N?o tem pessoal.
> > > J? falei com eles v?rias vezes numa boa e nunca consegui resolver.
> Tenho
> > 6
> > > ou 7 provedores com o mesmo problema. Alguns nem tem TR?NSITO com a
> > Level3
> > > mas eles acabam prendendo a rota mesmo assim. N?s vamos enviar uma
> > > notifica??o extra-judicial em nome de todos esses provedores. Vemos que
> > ? a
> > > ?nica forma de resolver.
> > >
> > > Em ter., 18 de ago. de 2020 ?s 16:32, Alexandre Aleixo | Opticalhost <
> > > alexandre at opticalhost.com.br> escreveu:
> > >
> > >> N?o tem ningu?m aqui da L3 que possa ver isso?
> > >>
> > >> Parece algo t?o simples, como uma configura??o de "hold time" do
> > >> keepalive em menor tempo, pra que a sess?o seja derrubada mais
> > >> rapidamente...
> > >>
> > >> Alexandre Aleixo
> > >>
> > >>
> > >>
> > >>
> > >> Em ter., 18 de ago. de 2020 ?s 15:50, Alysson Jose da Silva <
> > >> alyssonjose at gmail.com> escreveu:
> > >>
> > >>> Aconteceu aqui tamb?m, mas no AS 3549
> > >>>
> > >>> triste....
> > >>>
> > >>> Em 18/08/2020 15:29, Jo?o Butzke escreveu:
> > >>>> Acontece aqui no sul tambem, n?o ? privil?gio do norte rsrsrsrs
> > >>>>
> > >>>> Att,
> > >>>>
> > >>>> Em 17/08/2020 17:35, Vinicius Gruske Dorneles escreveu:
> > >>>>> Estou com um cliente do Norte do pa?s com rota presa no AS3556
> nesse
> > >>>>> exato momento. Estou tendo que anunciar o an?ncio /24, pois o /23
> > pela
> > >>>>> rota presa tem AS-PATH menor que o da outra operadora. Acabei de
> > ligar
> > >>>>> para o suporte da Century Link, e a menina me falou que um
> Engenheiro
> > >>>>> iria me retornar. Esperar para ver...
> > >>>>>
> > >>>>> Tenho um outro cliente que fecha sess?o com o AS3549 em Porto
> Alegre,
> > >>>>> que, igualmente ao relato do Vagner, n?o tem problemas com rota
> > presa.
> > >>>>>
> > >>>>> Mas eu percebi que esses problemas acontecem com ASNs que est?o
> mais
> > >>>>> pro norte do pa?s. O que faria sentido se o problema for em um
> > >>>>> roteador no Rio de Janeiro.
> > >>>>>
> > >>>>> Em seg., 17 de ago. de 2020 ?s 16:40, vagner silva sousa
> > >>>>> <vagnerss2011 at gmail.com> escreveu:
> > >>>>>> Na ?poca me relataram que o problema era porque estavam migrando o
> > >>>>>> AS3549
> > >>>>>> para o AS3356 e tinha um roteador no Rio de Janeiro que estava
> > >>>>>> desatualizado e estava prendendo os prefixos.
> > >>>>>>
> > >>>>>> Em seg., 17 de ago. de 2020 ?s 16:09, Vagner Felipe Becker <
> > >>>>>> vagner at nexsul.com.br> escreveu:
> > >>>>>>
> > >>>>>>> Rota presa?! Ser? que a L3 come?ou a adotar Mikrotik no core?!
> > >>>>>>>
> > >>>>>>> kkkk, brincadeiras a parte, tenho sess?o fechada com eles no
> AS3549
> > >> em
> > >>>>>>> Porto Alegre e nunca me aconteceu isso. Vou subir um peer nos
> > >> p?oximos
> > >>>>>>> dias por SP via bilateral no IX no AS3356, vou testar se o
> problema
> > >>>>>>> ocorre e posto pra vcs.
> > >>>>>>>
> > >>>>>>> Att,
> > >>>>>>>
> > >>>>>>> Vagner Felipe Becker
> > >>>>>>>
> > >>>>>>> Em 17/08/2020 14:16, Lucas Willian Bocchi escreveu:
> > >>>>>>>> Eu ja reclamei com o time de engenharia deles e nao tive
> retorno.
> > >>>>>>>> Tenho
> > >>>>>>>> esse problema a meses.
> > >>>>>>>> Sou a favor de tomar uma atitude mais r?gida em rela??o a isso.
> > >>>>>>>>
> > >>>>>>>> Em seg, 17 de ago de 2020 12:17, Robson F. Ramaldes <
> > >>>>>>> robson at netnew.com.br>
> > >>>>>>>> escreveu:
> > >>>>>>>>
> > >>>>>>>>> Boa tarde
> > >>>>>>>>>
> > >>>>>>>>> Peguei 2 casos em lugares diferentes com o mesmo problema
> > >>>>>>>>>
> > >>>>>>>>> Em um, retiramos os an?ncios da sess?o com eles e o
> > >>>>>>>>> outro caso foi um rompimento que derrubou a sess?o
> > >>>>>>>>>
> > >>>>>>>>> ambos as rotas ficaram "presas" nas consultas pelos looking
> glass
> > >>>>>>>>> s? resolveu anunciando o mesmo bloco id?ntico ou mais
> especifico
> > >> por
> > >>>>>>> outra
> > >>>>>>>>> operadora
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Att.
> > >>>>>>>>>
> > >>>>>>>>> Robson F. Ramaldes
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> -----Mensagem original-----
> > >>>>>>>>> De: gter <gter-bounces at eng.registro.br> Em nome de Charles
> > >> Barreto
> > >>>>>>> Macedo
> > >>>>>>>>> Enviada em: segunda-feira, 17 de agosto de 2020 11:31
> > >>>>>>>>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> > >>>>>>>>> gter at eng.registro.br>
> > >>>>>>>>> Assunto: Re: [GTER] Rota presa AS3356 Level3
> > >>>>>>>>>
> > >>>>>>>>> Bom Dia,
> > >>>>>>>>>
> > >>>>>>>>> Para n?s, ? um problema antigo...  J? aconteceu de demorar mais
> > >> de 6
> > >>>>>>> Horas
> > >>>>>>>>> para baixar os an?ncios..
> > >>>>>>>>>
> > >>>>>>>>> Em seg., 17 de ago. de 2020 ?s 11:16, Gabriel Wolp <
> > >>>>>>> paivgabriel at gmail.com>
> > >>>>>>>>> escreveu:
> > >>>>>>>>>
> > >>>>>>>>>> N?s paramos de anunciar para nossos upstreams um /21 inteiro
> as
> > >>>>>>>>>> 6 da
> > >>>>>>>>>> manh?, porem este ASN ainda mantem o /21 na sua tabela de
> > >>>>>>>>>> roteamento e
> > >>>>>>>>>> espalhando este bloco indevidamente, mesmo n?o estando sendo
> > >>>>>>>>>> anunciado
> > >>>>>>>>>> para nenhum de nossos upstreams. J? aconteceu isso com algu?m?
> > >>>>>>>>>> --
> > >>>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
> > >>>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> Atenciosamente,
> > >>>>>>>>>
> > >>>>>>>>> Charles Barreto
> > >>>>>>>>> Zoom Telecomunica??es
> > >>>>>>>>> (44) 31112-2477
> > >>>>>>>>>
> > >>>>>>>>> www.zoominternet.com.br<http://www.zoominternet.com.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
> > >>>>>>> --
> > >>>>>>>
> > >>>>>>> *Vagner Felipe Becker*
> > >>>>>>>
> > >>>>>>> Nexsul Conectividade
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Tel: +55(51)3712-7600 | +55(51)99754-4730
> > >>>>>>>
> > >>>>>>> Rod. RSC 453 KM 39,5, 609 - 101, CEP 95880-000
> > >>>>>>>
> > >>>>>>> Rio Grande do Sul, RS - Brasil
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Nexsul <https://www.nexsul.com.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
> > >>
> > > --
> > > 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
> >
>
>
> --
>
> *Andr? Bolzan Saar*
> *Andre.Bolzan at FIXFIBRA.com.br <Andre.Bolzan at FIXFIBRA.com.br>*
> **55 11 98205-7742*
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From lucas.bocchi at gmail.com  Thu Aug 20 19:48:36 2020
From: lucas.bocchi at gmail.com (Lucas Willian Bocchi)
Date: Thu, 20 Aug 2020 19:48:36 -0300
Subject: [GTER] RES: RES: Rota presa AS3356 Level3
In-Reply-To: <CAO4k365XA5FYG5gqZTr1mkhbYpHJVKhjp41oCt9yFOcuAYEJOQ@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
 <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
 <95b7c0ba-0319-1941-c361-21aa904567c9@naxi.com.br>
 <df36b6c6-0b81-4b5d-1e32-c8cef40d2b26@gmail.com>
 <CAO4k366S7kcT7Lfg11H9H8a+TfTusfUtiQjjtgzcMmMtKdkSRg@mail.gmail.com>
 <CA+m52=fnMt+qkK2uvJD5prVwb7SSz-kge5_zPZu0NXoKxkGb7g@mail.gmail.com>
 <9f408064-a062-8f07-c180-6e6a9d132e5f@gomais.com.br>
 <DM6PR01MB4938A5CD018FAA165DC1785FBB5C0@DM6PR01MB4938.prod.exchangelabs.com>
 <CAF1WzFHZ9Y5rfUVNhOqFSMdsR37ReMvziMykUtO0d_KL_MQqHQ@mail.gmail.com>
 <CAO4k365XA5FYG5gqZTr1mkhbYpHJVKhjp41oCt9yFOcuAYEJOQ@mail.gmail.com>
Message-ID: <CA+m52=eG6waLToEeLT1eaGPYaP7Sdt1xhK83CHJfvpw1fdrUpg@mail.gmail.com>

Mas a? ? s? manobra e manobra e manobra pra resolver um problema que n?o ?
teu...

From fhfrediani at gmail.com  Fri Aug 21 00:57:23 2020
From: fhfrediani at gmail.com (Fernando Frediani)
Date: Fri, 21 Aug 2020 00:57:23 -0300
Subject: [GTER] =?utf-8?q?Ajuste_de_Localpref=2C_MED_e_Participa=C3=A7?=
 =?utf-8?q?=C3=A3o_em_IX_Regionais?=
Message-ID: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>

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


From andre at bnet.com.br  Fri Aug 21 01:02:30 2020
From: andre at bnet.com.br (Andre Almeida)
Date: Fri, 21 Aug 2020 01:02:30 -0300
Subject: [GTER] =?utf-8?q?Ajuste_de_Localpref=2C_MED_e_Participa=C3=A7?=
	=?utf-8?q?=C3=A3o_em_IX_Regionais?=
In-Reply-To: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
References: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
Message-ID: <CAKAeHyEbg-9sPqWmoZdLRAVZN0O_9ZQeV_JyToSg3+T7qQi+pw@mail.gmail.com>

Pra quem tem bloco maior do que /24 daria pra anunciar mais espec?fico pro
regional tbm....

Em sex, 21 de ago de 2020 00:58, Fernando Frediani <fhfrediani at gmail.com>
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
>

From fhfrediani at gmail.com  Fri Aug 21 01:11:53 2020
From: fhfrediani at gmail.com (Fernando Frediani)
Date: Fri, 21 Aug 2020 01:11:53 -0300
Subject: [GTER] =?utf-8?q?Ajuste_de_Localpref=2C_MED_e_Participa=C3=A7?=
 =?utf-8?q?=C3=A3o_em_IX_Regionais?=
In-Reply-To: <CAKAeHyEbg-9sPqWmoZdLRAVZN0O_9ZQeV_JyToSg3+T7qQi+pw@mail.gmail.com>
References: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
 <CAKAeHyEbg-9sPqWmoZdLRAVZN0O_9ZQeV_JyToSg3+T7qQi+pw@mail.gmail.com>
Message-ID: <a88280a5-2ebb-4980-757c-a66709b559a2@gmail.com>

Ola Andr?

N?o recomendo anunciar mais espec?fico, mas anunciar sempre igual para 
ambos os IX, pois se feito dessa forma sugerida e com os Localpref e MED 
devidamente ajustados o tr?fego ir? fluir automaticamente sempre pelo 
caminho mais vantajoso para ambos os lados.

O tema de an?ncio mais espec?fico ? bastante controverso e eu 
pessoalmente vejo com reservas e recomendo evitar (mesmo para IX) a n?o 
ser que o Sistema Aut?nomo tenha uma raz?o muito forte e espec?fica para 
isso.

Abra?os
Fernando Frediani

On 21/08/2020 01:02, Andre Almeida wrote:
> Pra quem tem bloco maior do que /24 daria pra anunciar mais espec?fico pro
> regional tbm....
>
> Em sex, 21 de ago de 2020 00:58, Fernando Frediani <fhfrediani at gmail.com>
> 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

From rubensk at gmail.com  Fri Aug 21 01:40:41 2020
From: rubensk at gmail.com (Rubens Kuhl)
Date: Fri, 21 Aug 2020 01:40:41 -0300
Subject: [GTER] =?utf-8?q?Ajuste_de_Localpref=2C_MED_e_Participa=C3=A7?=
	=?utf-8?q?=C3=A3o_em_IX_Regionais?=
In-Reply-To: <CAKAeHyEbg-9sPqWmoZdLRAVZN0O_9ZQeV_JyToSg3+T7qQi+pw@mail.gmail.com>
References: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
 <CAKAeHyEbg-9sPqWmoZdLRAVZN0O_9ZQeV_JyToSg3+T7qQi+pw@mail.gmail.com>
Message-ID: <CAGFn2k350_QBRJ46ho3sWnem-E7PKJ=WwQf0fcNhcfALcb1EVg@mail.gmail.com>

On Fri, Aug 21, 2020 at 1:08 AM Andre Almeida <andre at bnet.com.br> wrote:
>
> Pra quem tem bloco maior do que /24 daria pra anunciar mais espec?fico pro
> regional tbm....


An?ncio mais espec?fico ? mais problema do que solu??o. Agora que
todos os IX tem communities, ? algo a usar seletivamente em an?ncios
para AS espec?ficos que se nota que o tr?fego de retorno esteja
sub-?timo. Mas anunciar mais espec?ficos no geral ? pedir para sofrer.


Rubens

From talesrodarte at gmail.com  Fri Aug 21 06:04:28 2020
From: talesrodarte at gmail.com (Tales Rodarte)
Date: Fri, 21 Aug 2020 06:04:28 -0300
Subject: [GTER] =?utf-8?q?Ajuste_de_Localpref=2C_MED_e_Participa=C3=A7?=
 =?utf-8?q?=C3=A3o_em_IX_Regionais?=
In-Reply-To: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
References: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
Message-ID: <2937b766-967d-d24f-e29b-26513070a5c7@gmail.com>

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



From sup.rafaelgaldino at gmail.com  Fri Aug 21 11:24:26 2020
From: sup.rafaelgaldino at gmail.com (Rafael Galdino)
Date: Fri, 21 Aug 2020 11:24:26 -0300
Subject: [GTER] RES: RES: Rota presa AS3356 Level3
In-Reply-To: <CA+m52=eG6waLToEeLT1eaGPYaP7Sdt1xhK83CHJfvpw1fdrUpg@mail.gmail.com>
References: <CAKUNjRN2QwKYyC4oytXT0tD1isuVCj00rgrKZd5EABLb0WOzPQ@mail.gmail.com>
 <CALHxhv+nEHP4hTbnqrZ+afhEGAHqcuHzG8QgjGeaYS2w5ELApQ@mail.gmail.com>
 <00fe01d674a8$ea9995f0$bfccc1d0$@netnew.com.br>
 <CA+m52=dgeTiaHQZq_3BfzjZED=don1si25CwBJLv+g9j=SGh-Q@mail.gmail.com>
 <720b434c-464c-c921-f6bc-afa1b90c4d5a@nexsul.com.br>
 <CAMJy3Yxdo-tgEYCjv-W6L-=q0JD86q0WzNdiT37xykYshiSbWQ@mail.gmail.com>
 <CAFVDtc-m7oCsupUjoBzig=2yperM=SsgWDO3sPjmvdVTe58XYA@mail.gmail.com>
 <95b7c0ba-0319-1941-c361-21aa904567c9@naxi.com.br>
 <df36b6c6-0b81-4b5d-1e32-c8cef40d2b26@gmail.com>
 <CAO4k366S7kcT7Lfg11H9H8a+TfTusfUtiQjjtgzcMmMtKdkSRg@mail.gmail.com>
 <CA+m52=fnMt+qkK2uvJD5prVwb7SSz-kge5_zPZu0NXoKxkGb7g@mail.gmail.com>
 <9f408064-a062-8f07-c180-6e6a9d132e5f@gomais.com.br>
 <DM6PR01MB4938A5CD018FAA165DC1785FBB5C0@DM6PR01MB4938.prod.exchangelabs.com>
 <CAF1WzFHZ9Y5rfUVNhOqFSMdsR37ReMvziMykUtO0d_KL_MQqHQ@mail.gmail.com>
 <CAO4k365XA5FYG5gqZTr1mkhbYpHJVKhjp41oCt9yFOcuAYEJOQ@mail.gmail.com>
 <CA+m52=eG6waLToEeLT1eaGPYaP7Sdt1xhK83CHJfvpw1fdrUpg@mail.gmail.com>
Message-ID: <CAPefbKrFPFJf8XX68YLQefPvYyTaci3A-E+UBdLCM2YvpjqL1g@mail.gmail.com>

ataque?? qual fonte disso? pq se for assim a Level 3 tendo esse problema
imagina n?s pobre mortais como ficamos?

Em qui., 20 de ago. de 2020 ?s 19:49, Lucas Willian Bocchi <
lucas.bocchi at gmail.com> escreveu:

> Mas a? ? s? manobra e manobra e manobra pra resolver um problema que n?o ?
> teu...
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 


*Rafael Galdino*


*http://Suporte.network <http://Suporte.network>*

       contato at suporte.network

      Phone:
*+55 (83) 98211-9090*


*Whatsapp: https://api.whatsapp.com/send?phone=5583982119090
<https://api.whatsapp.com/send?phone=5583982119090>*

From andre at bnet.com.br  Fri Aug 21 11:50:52 2020
From: andre at bnet.com.br (Andre Almeida)
Date: Fri, 21 Aug 2020 11:50:52 -0300
Subject: [GTER] =?utf-8?q?Ajuste_de_Localpref=2C_MED_e_Participa=C3=A7?=
	=?utf-8?q?=C3=A3o_em_IX_Regionais?=
In-Reply-To: <CAGFn2k350_QBRJ46ho3sWnem-E7PKJ=WwQf0fcNhcfALcb1EVg@mail.gmail.com>
References: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
 <CAKAeHyEbg-9sPqWmoZdLRAVZN0O_9ZQeV_JyToSg3+T7qQi+pw@mail.gmail.com>
 <CAGFn2k350_QBRJ46ho3sWnem-E7PKJ=WwQf0fcNhcfALcb1EVg@mail.gmail.com>
Message-ID: <CAKAeHyGxqwbUDZHaD0j+1Kb8n_RrL18j8YbPHj6pk+Qjf64p2A@mail.gmail.com>

Ent?o deveriam alterar isso quando h? ativa??o no IX. Sempre recebemos um
e-mail com esse texto:

"Quando voc? terminar suas configura??es, n?o conseguir? ainda testar a
conectividade IP (ping), nem as sess?es BGP subir?o ainda. Isso ? normal, a
rede ainda n?o est? configurada no IX.br.  Avise-nos quando tudo estiver
pronto e, em breve, faremos as configura??es no IX.br e entraremos na fase
de testes. ? importante que os prefixos anunciados nas sess?es com os Route
Servers sejam mais espec?ficos (mais longos) do que aqueles anunciados para
seus provedores de tr?nsito."


Se aconselham usar prefixos mais longos pro IX do que pra tr?nsito, n?o
vejo pq n?o fazer tamb?m para onde quer se preferir.
A ?nica desvantagem disso ? um aumento na tabela de roteamento e quem
possui apenas um /24 n?o conseguir fazer.

Que fique claro que eu tamb?m sou a favor do local pref e MED, faz mais
sentido pra mim.
O problema ? que isso depende de cada sistema aut?nomo realizar a mesma
coisa.

E sinceramente, no IX-SP, com os problemas que estamos enfrentando com
resolu??o de ARP, nunca que eu vou deixar local-pref priorit?rio por ali.
Isso sim ? mais problema do que solu??o.


Andre

Em sex., 21 de ago. de 2020 ?s 01:41, Rubens Kuhl <rubensk at gmail.com>
escreveu:

> On Fri, Aug 21, 2020 at 1:08 AM Andre Almeida <andre at bnet.com.br> wrote:
> >
> > Pra quem tem bloco maior do que /24 daria pra anunciar mais espec?fico
> pro
> > regional tbm....
>
>
> An?ncio mais espec?fico ? mais problema do que solu??o. Agora que
> todos os IX tem communities, ? algo a usar seletivamente em an?ncios
> para AS espec?ficos que se nota que o tr?fego de retorno esteja
> sub-?timo. Mas anunciar mais espec?ficos no geral ? pedir para sofrer.
>
>
> Rubens
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From fischerdouglas at gmail.com  Fri Aug 21 12:22:21 2020
From: fischerdouglas at gmail.com (Douglas Fischer)
Date: Fri, 21 Aug 2020 12:22:21 -0300
Subject: [GTER] =?utf-8?q?Ajuste_de_Localpref=2C_MED_e_Participa=C3=A7?=
	=?utf-8?q?=C3=A3o_em_IX_Regionais?=
In-Reply-To: <CAKAeHyGxqwbUDZHaD0j+1Kb8n_RrL18j8YbPHj6pk+Qjf64p2A@mail.gmail.com>
References: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
 <CAKAeHyEbg-9sPqWmoZdLRAVZN0O_9ZQeV_JyToSg3+T7qQi+pw@mail.gmail.com>
 <CAGFn2k350_QBRJ46ho3sWnem-E7PKJ=WwQf0fcNhcfALcb1EVg@mail.gmail.com>
 <CAKAeHyGxqwbUDZHaD0j+1Kb8n_RrL18j8YbPHj6pk+Qjf64p2A@mail.gmail.com>
Message-ID: <CAKEr4RSPgLYkV0M3CXFrc9EjLCJv+ndb__zs7nXDf-PYGnhtLA@mail.gmail.com>

A) Quem usa mais que 3 prepends est? fazendo CAGADA!
Est? abrindo as portas para tomar um sequestro de bloco que nem o RPKI vai
te salvar.

B) Quem anuncia prefixos mais espec?ficos por caminhos diferentes est?
expondo seus clientes a qualidade Internet DIFERENTES.
Al?m de aumentar exponencialmente a probabilidade de problemas que a
assimetria pode te trazer(n?o deveria, mas de fato traz).
Tamb?m tem os fatos esdr?xulos "nesse cliente funciona e nesse outro n?o
funciona"... E quando vai ver ? porque est?o em /24 diferentes e pacotes de
retorno passando por caminhos diferentes.
(N?o preciso nem falar do impacto negativo do aumento da tabela global, n??)

C) Quem for?a Local-Pref para todo as rotas de um IXP CERTAMENTE est?
usando caminhos PIORES em alguma situa??o!
Seja para o ASN vizinho de porta que est? indo l? longe para conversar.
Ou seja para o ASN j? ? de l? de longe e que vai ter que ir para um caminho
um pouco mais longe ainda...

 - PAREM DE ANUNCIAR MAIS ESPEC?FICO!
 - PAREM DE USAR PREPEND COMO SE ESTIVEM COMENDO NUTELLA DE COLHERADA.
 - PAREM DE ESTUPRAR O LOCAL-PREF ALUCINADAMENTE
   (Na condi??o mais comum de escolha de rotas BGP, ? O CRIT?RIO MAIS FORTE
do BGP. Quase sempre ? como usar tiro de canh?o para matar mosquito)





Em sex., 21 de ago. de 2020 ?s 11:51, Andre Almeida <andre at bnet.com.br>
escreveu:

> Ent?o deveriam alterar isso quando h? ativa??o no IX. Sempre recebemos um
> e-mail com esse texto:
>
> "Quando voc? terminar suas configura??es, n?o conseguir? ainda testar a
> conectividade IP (ping), nem as sess?es BGP subir?o ainda. Isso ? normal, a
> rede ainda n?o est? configurada no IX.br.  Avise-nos quando tudo estiver
> pronto e, em breve, faremos as configura??es no IX.br e entraremos na fase
> de testes. ? importante que os prefixos anunciados nas sess?es com os Route
> Servers sejam mais espec?ficos (mais longos) do que aqueles anunciados para
> seus provedores de tr?nsito."
>
>
> Se aconselham usar prefixos mais longos pro IX do que pra tr?nsito, n?o
> vejo pq n?o fazer tamb?m para onde quer se preferir.
> A ?nica desvantagem disso ? um aumento na tabela de roteamento e quem
> possui apenas um /24 n?o conseguir fazer.
>
> Que fique claro que eu tamb?m sou a favor do local pref e MED, faz mais
> sentido pra mim.
> O problema ? que isso depende de cada sistema aut?nomo realizar a mesma
> coisa.
>
> E sinceramente, no IX-SP, com os problemas que estamos enfrentando com
> resolu??o de ARP, nunca que eu vou deixar local-pref priorit?rio por ali.
> Isso sim ? mais problema do que solu??o.
>
>
> Andre
>
> Em sex., 21 de ago. de 2020 ?s 01:41, Rubens Kuhl <rubensk at gmail.com>
> escreveu:
>
> > On Fri, Aug 21, 2020 at 1:08 AM Andre Almeida <andre at bnet.com.br> wrote:
> > >
> > > Pra quem tem bloco maior do que /24 daria pra anunciar mais espec?fico
> > pro
> > > regional tbm....
> >
> >
> > An?ncio mais espec?fico ? mais problema do que solu??o. Agora que
> > todos os IX tem communities, ? algo a usar seletivamente em an?ncios
> > para AS espec?ficos que se nota que o tr?fego de retorno esteja
> > sub-?timo. Mas anunciar mais espec?ficos no geral ? pedir para sofrer.
> >
> >
> > Rubens
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Douglas Fernando Fischer
Eng? de Controle e Automa??o

From fischerdouglas at gmail.com  Fri Aug 21 12:22:38 2020
From: fischerdouglas at gmail.com (Douglas Fischer)
Date: Fri, 21 Aug 2020 12:22:38 -0300
Subject: [GTER] =?utf-8?q?Ajuste_de_Localpref=2C_MED_e_Participa=C3=A7?=
	=?utf-8?q?=C3=A3o_em_IX_Regionais?=
In-Reply-To: <CAKEr4RSPgLYkV0M3CXFrc9EjLCJv+ndb__zs7nXDf-PYGnhtLA@mail.gmail.com>
References: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
 <CAKAeHyEbg-9sPqWmoZdLRAVZN0O_9ZQeV_JyToSg3+T7qQi+pw@mail.gmail.com>
 <CAGFn2k350_QBRJ46ho3sWnem-E7PKJ=WwQf0fcNhcfALcb1EVg@mail.gmail.com>
 <CAKAeHyGxqwbUDZHaD0j+1Kb8n_RrL18j8YbPHj6pk+Qjf64p2A@mail.gmail.com>
 <CAKEr4RSPgLYkV0M3CXFrc9EjLCJv+ndb__zs7nXDf-PYGnhtLA@mail.gmail.com>
Message-ID: <CAKEr4RRoKf=06yFQkzRYGii=qCKWnw9z8xjnzHjrrUinPGx7vw@mail.gmail.com>

  Antigamente(10-15 anos atr?s), dois ASNs se encontrando e localiza??es
geogr?ficas diferentes era coisa s? de Tier 1.
Com o advento dos IXPs mudo afora, isso mudou! E mudou RADICALMENTE!

No LACNOG 2020 que acontecer? entre 5 e 9 de Outubro, farei uma
apresenta??o correlata a esse tema.

BGP MED baseado na lat?ncia - Uma m?trica simples, eficaz, e altamente
padroniz?vel de se resolver BGP potatoes
Antecipando os devidos cr?ditos:
Minha primeira inspira??o sobre isso foi numa apresenta??o do Rinaldo Vaz
em um PTT-Forum das antigas...
Mais recentemente, aprendi que a Cogent utiliza a lat?ncia estimada em
microsegundos informado no par?metro MED.
Estou em trabalho conjunto com uma Carrier para experimenta??o dessa
metodologia como padr?o.



Em sex., 21 de ago. de 2020 ?s 12:22, Douglas Fischer <
fischerdouglas at gmail.com> escreveu:

>
> A) Quem usa mais que 3 prepends est? fazendo CAGADA!
> Est? abrindo as portas para tomar um sequestro de bloco que nem o RPKI vai
> te salvar.
>
> B) Quem anuncia prefixos mais espec?ficos por caminhos diferentes est?
> expondo seus clientes a qualidade Internet DIFERENTES.
> Al?m de aumentar exponencialmente a probabilidade de problemas que a
> assimetria pode te trazer(n?o deveria, mas de fato traz).
> Tamb?m tem os fatos esdr?xulos "nesse cliente funciona e nesse outro n?o
> funciona"... E quando vai ver ? porque est?o em /24 diferentes e pacotes de
> retorno passando por caminhos diferentes.
> (N?o preciso nem falar do impacto negativo do aumento da tabela global,
> n??)
>
> C) Quem for?a Local-Pref para todo as rotas de um IXP CERTAMENTE est?
> usando caminhos PIORES em alguma situa??o!
> Seja para o ASN vizinho de porta que est? indo l? longe para conversar.
> Ou seja para o ASN j? ? de l? de longe e que vai ter que ir para um
> caminho um pouco mais longe ainda...
>
>  - PAREM DE ANUNCIAR MAIS ESPEC?FICO!
>  - PAREM DE USAR PREPEND COMO SE ESTIVEM COMENDO NUTELLA DE COLHERADA.
>  - PAREM DE ESTUPRAR O LOCAL-PREF ALUCINADAMENTE
>    (Na condi??o mais comum de escolha de rotas BGP, ? O CRIT?RIO MAIS
> FORTE do BGP. Quase sempre ? como usar tiro de canh?o para matar mosquito)
>
>
>
>
>
> Em sex., 21 de ago. de 2020 ?s 11:51, Andre Almeida <andre at bnet.com.br>
> escreveu:
>
>> Ent?o deveriam alterar isso quando h? ativa??o no IX. Sempre recebemos um
>> e-mail com esse texto:
>>
>> "Quando voc? terminar suas configura??es, n?o conseguir? ainda testar a
>> conectividade IP (ping), nem as sess?es BGP subir?o ainda. Isso ? normal,
>> a
>> rede ainda n?o est? configurada no IX.br.  Avise-nos quando tudo estiver
>> pronto e, em breve, faremos as configura??es no IX.br e entraremos na fase
>> de testes. ? importante que os prefixos anunciados nas sess?es com os
>> Route
>> Servers sejam mais espec?ficos (mais longos) do que aqueles anunciados
>> para
>> seus provedores de tr?nsito."
>>
>>
>> Se aconselham usar prefixos mais longos pro IX do que pra tr?nsito, n?o
>> vejo pq n?o fazer tamb?m para onde quer se preferir.
>> A ?nica desvantagem disso ? um aumento na tabela de roteamento e quem
>> possui apenas um /24 n?o conseguir fazer.
>>
>> Que fique claro que eu tamb?m sou a favor do local pref e MED, faz mais
>> sentido pra mim.
>> O problema ? que isso depende de cada sistema aut?nomo realizar a mesma
>> coisa.
>>
>> E sinceramente, no IX-SP, com os problemas que estamos enfrentando com
>> resolu??o de ARP, nunca que eu vou deixar local-pref priorit?rio por ali.
>> Isso sim ? mais problema do que solu??o.
>>
>>
>> Andre
>>
>> Em sex., 21 de ago. de 2020 ?s 01:41, Rubens Kuhl <rubensk at gmail.com>
>> escreveu:
>>
>> > On Fri, Aug 21, 2020 at 1:08 AM Andre Almeida <andre at bnet.com.br>
>> wrote:
>> > >
>> > > Pra quem tem bloco maior do que /24 daria pra anunciar mais espec?fico
>> > pro
>> > > regional tbm....
>> >
>> >
>> > An?ncio mais espec?fico ? mais problema do que solu??o. Agora que
>> > todos os IX tem communities, ? algo a usar seletivamente em an?ncios
>> > para AS espec?ficos que se nota que o tr?fego de retorno esteja
>> > sub-?timo. Mas anunciar mais espec?ficos no geral ? pedir para sofrer.
>> >
>> >
>> > Rubens
>> > --
>> > gter list    https://eng.registro.br/mailman/listinfo/gter
>> >
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
>
> --
> Douglas Fernando Fischer
> Eng? de Controle e Automa??o
>


-- 
Douglas Fernando Fischer
Eng? de Controle e Automa??o

From josivan.barbosa01 at gmail.com  Fri Aug 21 10:46:51 2020
From: josivan.barbosa01 at gmail.com (Josivan Barbosa)
Date: Fri, 21 Aug 2020 10:46:51 -0300
Subject: [GTER] =?utf-8?q?Ajuste_de_Localpref=2C_MED_e_Participa=C3=A7?=
	=?utf-8?q?=C3=A3o_em_IX_Regionais?=
In-Reply-To: <2937b766-967d-d24f-e29b-26513070a5c7@gmail.com>
References: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
 <2937b766-967d-d24f-e29b-26513070a5c7@gmail.com>
Message-ID: <CAF3jt9XvFOgXjNALR1gs5kOoK23X7Karoy1DUmPLpi1qsXsZAQ@mail.gmail.com>

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

From alexandre at onda.net.br  Sat Aug 22 19:13:49 2020
From: alexandre at onda.net.br (Alexandre J. Correa (Onda))
Date: Sat, 22 Aug 2020 19:13:49 -0300
Subject: [GTER] IX-SPO ARP (Era: [IX.br] [Info] Peering Amazon / AWS -
 AS16509)
In-Reply-To: <CAGFn2k14uYkfL8A6qqevtD6iR2rb_c5GDR59Pb7J4Pnpv7ovcw@mail.gmail.com>
References: <20200814200950.1C6EB416B6@meu-ix.in.ix.br>
 <15877939-aeea-ab18-7cc6-30ea44ceaf34@specialist.srv.br>
 <CP2PR80MB3635BC15F985A64695FD20EFF5410@CP2PR80MB3635.lamprd80.prod.outlook.com>
 <acaf3b1b-52b0-9d72-084c-9174929abd12@specialist.srv.br>
 <CAKAeHyFFk53pVdfrpQghnP6WGk+_s39fdfJZFn346pdFfR8rxg@mail.gmail.com>
 <CAEHShq_-x5jVQPTwrF3_iWE+uqbvTEY_tn0zXCGYz3QYuO_J-Q@mail.gmail.com>
 <CAPo9HYea7iC1sUrYc2-2MX=HoOvap7oWN_aOyNgcV=tC=R9czg@mail.gmail.com>
 <CAKAeHyG=HeppPbA3jFKY9SYPnFWK949uV2FY0T2XwJwqrfGjag@mail.gmail.com>
 <CAGFn2k2CgwARNoA=ki71khJzf07dTqrUm7Ad8sEYrTdC_MF4AA@mail.gmail.com>
 <CAKAeHyEnOBzcWPzaKfuR8CGY=yub0foNpcv4o5dKKX0HRqQ_8w@mail.gmail.com>
 <CAGFn2k14uYkfL8A6qqevtD6iR2rb_c5GDR59Pb7J4Pnpv7ovcw@mail.gmail.com>
Message-ID: <fa2e7b06-3c0f-251e-e1dc-c471ead1807e@onda.net.br>

Exemplo do que esta ocorrendo neste minuto:

ROUTER01> display arp interface Eth-TrunkX.XXXX | include 187.16.218.144
IP ADDRESS????? MAC ADDRESS???? EXPIRE(M) TYPE??????? INTERFACE VPN-INSTANCE
 ????????????????????????????????????????? VLAN/CEVLAN PVC
------------------------------------------------------------------------------
187.16.218.144? 3c94-d511-3fcd? 37??????? D-0 Eth-TrunkX.XXXX
------------------------------------------------------------------------------
Total:1924???????? Dynamic:1923?????? Static:0??? Interface:1 Remote:0

ping 187.16.218.144
 ? PING 187.16.218.144: 56? data bytes, press CTRL_C to break
 ??? Reply from 187.16.218.144: bytes=56 Sequence=1 ttl=64 time=7 ms
 ??? Reply from 187.16.218.144: bytes=56 Sequence=2 ttl=64 time=7 ms
 ??? Reply from 187.16.218.144: bytes=56 Sequence=3 ttl=64 time=7 ms
 ??? Reply from 187.16.218.144: bytes=56 Sequence=4 ttl=64 time=7 ms
 ??? Reply from 187.16.218.144: bytes=56 Sequence=5 ttl=64 time=7 ms


ROUTER02>display arp interface Eth-TrunkY.YYYY | include 187.16.218.144
IP ADDRESS????? MAC ADDRESS???? EXPIRE(M) TYPE??????? INTERFACE VPN-INSTANCE
 ????????????????????????????????????????? VLAN/CEVLAN PVC
------------------------------------------------------------------------------
187.16.218.144? 3c94-d511-3fcd? 10??????? D-0 Eth-TrunkY.YYYY
------------------------------------------------------------------------------
Total:1882???????? Dynamic:1881?????? Static:0??? Interface:1 Remote:0

ping 187.16.218.144
 ? PING 187.16.218.144: 56? data bytes, press CTRL_C to break
 ??? Request time out
 ??? Request time out
 ??? Request time out
 ??? Request time out
 ??? Request time out


Frequentemente isto acontece.....? e resolve sozinho.



Em 16/08/2020 17:04, Rubens Kuhl escreveu:
> On Sun, Aug 16, 2020 at 4:53 PM Andre Almeida <andre at bnet.com.br> wrote:
>> pode n?o ser a solu??o definitiva, mas vai diminuir bastante o tr?fego de
>> arp broadcast que rola no ATM. Talvez isso melhore e solucione esses arps
>> que n?o resolvem nem a pau.
>
> N?o ? nem solu??o definitiva nem tempor?ria, apenas um amplificador
> adicional de instabilidades.
>
>
> Rubens
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter


-
Alexandre Jeronimo Correa


From sup.rafaelgaldino at gmail.com  Sun Aug 23 13:25:59 2020
From: sup.rafaelgaldino at gmail.com (Rafael Galdino)
Date: Sun, 23 Aug 2020 13:25:59 -0300
Subject: [GTER] =?utf-8?q?Ajuste_de_Localpref=2C_MED_e_Participa=C3=A7?=
	=?utf-8?q?=C3=A3o_em_IX_Regionais?=
In-Reply-To: <CAF3jt9XvFOgXjNALR1gs5kOoK23X7Karoy1DUmPLpi1qsXsZAQ@mail.gmail.com>
References: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
 <2937b766-967d-d24f-e29b-26513070a5c7@gmail.com>
 <CAF3jt9XvFOgXjNALR1gs5kOoK23X7Karoy1DUmPLpi1qsXsZAQ@mail.gmail.com>
Message-ID: <CAPefbKoySuE5bVbzV9vvQpDm1v6ZS+7RHE2KbJZioX_UquBv1w@mail.gmail.com>

concordo contigo Douglas, ainda vejo empresas de tr?nsito fazendo o uso de
prepend como se fosse a ?nica forma de balancear os clientes de tr?nsito.
na maioria das vezes o cara tem uns 3 links com velocidades diferentes e
fica abusando at? a alma para balancear.
tenho um cliente que pra ele chegar a uma operadora digamos com internet
passa por uns 6 prepends....
 j? falei.... adianta?

esperava muito que o pessoal sa?sse da zona de conforto e desse uma
estudada melhor em BGP....

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
>


-- 


*Rafael Galdino*


*http://Suporte.network <http://Suporte.network>*

       contato at suporte.network

      Phone:
*+55 (83) 98211-9090*


*Whatsapp: https://api.whatsapp.com/send?phone=5583982119090
<https://api.whatsapp.com/send?phone=5583982119090>*

From emorales at nic.br  Mon Aug 24 07:51:32 2020
From: emorales at nic.br (Eduardo Morales)
Date: Mon, 24 Aug 2020 07:51:32 -0300
Subject: [GTER] =?utf-8?q?Come=C3=A7a_a_Semana_de_Capacita=C3=A7=C3=A3o_O?=
 =?utf-8?q?n-line_do_NIC=2Ebr=3A_minicursos_trazem_as_boas_pr=C3=A1ticas_p?=
 =?utf-8?q?ara_a_infraestrutura_de_redes!?=
Message-ID: <2cad4962-c2c3-321a-c683-c2f6027b9dad@nic.br>

Ol? Pessoal,


De hoje (24 de agosto) at? sexta-feira (28/8), promoveremos a Semana de 
Capacita??o On-line do NIC.br!

Renomados especialistas apresentar?o minicursos de alto n?vel t?cnico 
sobre as novas tecnologias e boas pr?ticas essenciais no dia a dia dos 
provedores e administradores de redes. S?o eles: Adalberto Lins (Cisco), 
Josiane de Barros Silva (ScanSource), Daniel Fink e Nicol?s Antoniello 
(ICANN), Lacier Da Costa Dias Junior e Luiz Puppin (VLSM), Eduardo R. 
Lopes de Haro (Juniper/WZTECH), al?m de Andrea Erina Komo, Eduardo 
Barasal Morales e Tiago Jun Nakamura (NIC.br).

Acompanhe os cursos pelo YouTube do NIC.br, nos links abaixo, sempre das 
9h ?s 12h (UTC-3), de forma gratuita e com direito a certifica??o!

24/8 - SEGURAN?A NO ROTEAMENTO COM RPKI : 
https://www.youtube.com/watch?v=jSvMCjPoFME
25/8 - SEGURAN?A B?SICA PARA UM PROVEDOR : 
https://www.youtube.com/watch?v=Ko9YkLA29ew
26/8 - IMPLEMENTA??O DE SERVIDORES RECURSIVOS (BIND E UNBOUND) COM 
DNSSEC E HYPERLOCAL : https://www.youtube.com/watch?v=N9tayhWRS0I
27/8 - AUTOMATIZA??O DE AN?NCIOS DE TR?NSITO BGP COM COMMUNITIES E VRF 
USANDO HUAWEI E MIKROTIK : https://www.youtube.com/watch?v=Y4JJgoX96PI
28/8 - EVOLU??O DA TECNOLOGIA DE TRANSPORTE LAYER 2 ? ETHERNET VPN : 
https://www.youtube.com/watch?v=G06S_PTSOZk

Consulte em https://semanacap.bcp.nic.br/0-online/ a agenda de cada dia 
e n?o perca os de seu interesse.

Abs,

Eduardo Barasal Morales


From fischerdouglas at gmail.com  Mon Aug 24 08:56:42 2020
From: fischerdouglas at gmail.com (Douglas Fischer)
Date: Mon, 24 Aug 2020 08:56:42 -0300
Subject: [GTER] =?utf-8?q?Ajuste_de_Localpref=2C_MED_e_Participa=C3=A7?=
	=?utf-8?q?=C3=A3o_em_IX_Regionais?=
In-Reply-To: <CAF3jt9XvFOgXjNALR1gs5kOoK23X7Karoy1DUmPLpi1qsXsZAQ@mail.gmail.com>
References: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
 <2937b766-967d-d24f-e29b-26513070a5c7@gmail.com>
 <CAF3jt9XvFOgXjNALR1gs5kOoK23X7Karoy1DUmPLpi1qsXsZAQ@mail.gmail.com>
Message-ID: <CAKEr4RQqEVZNFAqpYY6DT1fEFgiC-YnM+vjA7oBB6uZXsUxAEg@mail.gmail.com>

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

From josivan.barbosa01 at gmail.com  Mon Aug 24 15:22:27 2020
From: josivan.barbosa01 at gmail.com (Josivan Barbosa)
Date: Mon, 24 Aug 2020 15:22:27 -0300
Subject: [GTER] =?utf-8?q?Ajuste_de_Localpref=2C_MED_e_Participa=C3=A7?=
	=?utf-8?q?=C3=A3o_em_IX_Regionais?=
In-Reply-To: <CAKEr4RQqEVZNFAqpYY6DT1fEFgiC-YnM+vjA7oBB6uZXsUxAEg@mail.gmail.com>
References: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
 <2937b766-967d-d24f-e29b-26513070a5c7@gmail.com>
 <CAF3jt9XvFOgXjNALR1gs5kOoK23X7Karoy1DUmPLpi1qsXsZAQ@mail.gmail.com>
 <CAKEr4RQqEVZNFAqpYY6DT1fEFgiC-YnM+vjA7oBB6uZXsUxAEg@mail.gmail.com>
Message-ID: <CAF3jt9XZFELivrbgxsHEQexDgQjr6+=oEK_thAsvN1o0O-SjxA@mail.gmail.com>

Ol? Douglas!

N?o fico incomodado n?o ( T? at? aceito o convite no Facebook... kkkkkk ).

Vou explicar com mais detalhes o meu cen?rio:

Participo de duas localidades no meu estado (inclusive abrigo PIXes) que
est?o, mais ou menos, 150km de dist?ncia uma da outra, mais 2 outras
localidades regionais e o  IX.br SP (via transporte). Meus "vizinhos"
(Alguns ficam praticamente no mesmo bairro ) participam de pelo menos uma
das duas localidades e do IX.br SP.
Assim ficam com o mesmo aspath. Para o pacote n?o ter que passear em SP pra
chegar no meu vizinho de porta, acabei usando esse "m?todo" (Isso vem desde
a ?poca sem communities). A RNP, por exemplo, que est? em todas as
localidades que participo, seria melhor "entrar" na rede dela no meu POP
que abriga o PIX ou s? em SP via transporte?

J? me deparei com situa??es parecidas com a que vc relatou, mas a tratei
como exce??o nos filtros. Assim, questiono: quais das duas situa??es
deveria ser tratada como exce??o?


Em seg., 24 de ago. de 2020 ?s 08:57, Douglas Fischer <
fischerdouglas at gmail.com> escreveu:

> 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Att

Josivan Barbosa

From emorales at nic.br  Tue Aug 25 08:16:26 2020
From: emorales at nic.br (Eduardo Morales)
Date: Tue, 25 Aug 2020 08:16:26 -0300
Subject: [GTER] =?utf-8?q?Daqui_a_pouco=2C_=C3=A0s_9h_=28hor=C3=A1rio_de_?=
 =?utf-8?b?QnJhc8OtbGlhKTogU2VtYW5hIGRlIENhcGFjaXRhw6fDo28gLSBTRUdVUkFO?=
 =?utf-8?q?=C3=87A_B=C3=81SICA_PARA_UM_PROVEDOR?=
Message-ID: <edfd4c38-955d-d84c-0145-acef517c9f81@nic.br>

Ol? Pessoal,


O segundo dia da semana de capacita??o est? para come?ar. N?o percam, as 
9h (hor?rio de Bras?lia), teremos SEGURAN?A B?SICA PARA UM PROVEDOR. 
Veja a sua ementa:


Entendenda os riscos do sequestro de tr?fego, registro DNS, ataques 
DDoS, t?ticas de minera??o ilegal e Comando e controle:

- BGP Hijacking.

- DNS Hijacking.

- Criptojacking.

- Comand & Control(C2)

- DDoS

- Demonstra??o de como prevenir e bloquear algumas dessas amea?as.

Palestrantes:

Adalberto Lins (CISCO)
Josiane de Barros Silva (ScanSource)


Assista em https://youtu.be/Ko9YkLA29ew . Teremos certificado para quem 
acompanhar o evento ao vivo.


Abs,

Eduardo Barasal Morales


From andre.bolzan at fixfibra.com.br  Tue Aug 25 11:38:27 2020
From: andre.bolzan at fixfibra.com.br (Andre Bolzan)
Date: Tue, 25 Aug 2020 11:38:27 -0300
Subject: [GTER] =?utf-8?q?Ajuste_de_Localpref=2C_MED_e_Participa=C3=A7?=
	=?utf-8?q?=C3=A3o_em_IX_Regionais?=
In-Reply-To: <CAF3jt9XZFELivrbgxsHEQexDgQjr6+=oEK_thAsvN1o0O-SjxA@mail.gmail.com>
References: <debfa14c-4854-9279-1517-c40bd916abc1@gmail.com>
 <2937b766-967d-d24f-e29b-26513070a5c7@gmail.com>
 <CAF3jt9XvFOgXjNALR1gs5kOoK23X7Karoy1DUmPLpi1qsXsZAQ@mail.gmail.com>
 <CAKEr4RQqEVZNFAqpYY6DT1fEFgiC-YnM+vjA7oBB6uZXsUxAEg@mail.gmail.com>
 <CAF3jt9XZFELivrbgxsHEQexDgQjr6+=oEK_thAsvN1o0O-SjxA@mail.gmail.com>
Message-ID: <CAF1WzFENP09Ln6TA=2F_16xgJGq8hfPe37naQiYHwAi8OspPZA@mail.gmail.com>

@Douglas Fischer eu te odeio...

ME faz pensar diferente do "comum"... Cen?rio ficou muito claro...

Parab?ns pelo material... Ansioso pela apresenta??o ...

Em seg., 24 de ago. de 2020 ?s 15:22, Josivan Barbosa <
josivan.barbosa01 at gmail.com> escreveu:

> Ol? Douglas!
>
> N?o fico incomodado n?o ( T? at? aceito o convite no Facebook... kkkkkk ).
>
> Vou explicar com mais detalhes o meu cen?rio:
>
> Participo de duas localidades no meu estado (inclusive abrigo PIXes) que
> est?o, mais ou menos, 150km de dist?ncia uma da outra, mais 2 outras
> localidades regionais e o  IX.br SP (via transporte). Meus "vizinhos"
> (Alguns ficam praticamente no mesmo bairro ) participam de pelo menos uma
> das duas localidades e do IX.br SP.
> Assim ficam com o mesmo aspath. Para o pacote n?o ter que passear em SP pra
> chegar no meu vizinho de porta, acabei usando esse "m?todo" (Isso vem desde
> a ?poca sem communities). A RNP, por exemplo, que est? em todas as
> localidades que participo, seria melhor "entrar" na rede dela no meu POP
> que abriga o PIX ou s? em SP via transporte?
>
> J? me deparei com situa??es parecidas com a que vc relatou, mas a tratei
> como exce??o nos filtros. Assim, questiono: quais das duas situa??es
> deveria ser tratada como exce??o?
>
>
> Em seg., 24 de ago. de 2020 ?s 08:57, Douglas Fischer <
> fischerdouglas at gmail.com> escreveu:
>
> > 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
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
> --
> Att
>
> Josivan Barbosa
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 

*Andr? Bolzan Saar*
*Andre.Bolzan at FIXFIBRA.com.br <Andre.Bolzan at FIXFIBRA.com.br>*
**55 11 98205-7742*

From emorales at nic.br  Wed Aug 26 08:19:52 2020
From: emorales at nic.br (Eduardo Morales)
Date: Wed, 26 Aug 2020 08:19:52 -0300
Subject: [GTER] =?utf-8?q?Daqui_a_pouco=2C_=C3=A0s_9h_=28hor=C3=A1rio_de_?=
 =?utf-8?q?Bras=C3=ADlia=29=3A_Semana_de_Capacita=C3=A7=C3=A3o_-_IMPLEMENT?=
 =?utf-8?q?A=C3=87=C3=83O_DE_SERVIDORES_RECURSIVOS_=28BIND_E_UNBOUND=29_CO?=
 =?utf-8?q?M_DNSSEC_E_HYPERLOCAL?=
Message-ID: <d625bd94-d87b-cdf5-c25e-ad3668ac4ead@nic.br>

Ol? Pessoal,


O terceiro dia da semana de capacita??o est? para come?ar. N?o percam, 
as 9h (hor?rio de Bras?lia), teremos IMPLEMENTA??O DE SERVIDORES 
RECURSIVOS (BIND E UNBOUND) COM DNSSEC E HYPERLOCAL. Veja a sua ementa:


Uma implementa??o de DNS bem estruturada e moderna ? muito importante 
para a qualidade de servi?os do provedor. Hoje em dia dispomos de 
protocolos que aumentam a seguran?a e a performance de um servidor 
recursivo que podem ser implementadas de maneiras bastante simples, uma 
vez que certos cuidados sejam levados em conta. Este ? o caso do 
protocolo de Extens?es de Seguran?a do DNS (DNSSEC) e da c?pia local da 
zona raiz (hyperlocal). Neste tutorial faremos a implementa??o did?tica 
de dois servidores recursivos populares (BIND e Unbound) em servidores 
virtuais Xubuntu e CentOS8 atrav?s de um passo-a-passo que os alunos 
podem realizar em conjunto com a apresenta??o. Abordaremos a instala??o 
dos pacotes de software dos servidores recursivos, configura??o de 
DNSSEC e hyperlocal e testes ?teis ap?s a instala??o. Para participar, 
prepare seus downloads e instala??es pr?vias de acordo com o manual 
disponibilizado e nos vemos no treinamento.

Palestrantes:

Daniel Fink (ICANN)
Nicol?s Antoniello (ICANN)

Assista em https://youtu.be/N9tayhWRS0I . Teremos certificado para quem 
acompanhar o evento ao vivo.


Abs,

Eduardo Barasal Morales


From emorales at nic.br  Thu Aug 27 08:16:27 2020
From: emorales at nic.br (Eduardo Morales)
Date: Thu, 27 Aug 2020 08:16:27 -0300
Subject: [GTER] =?utf-8?q?Daqui_a_pouco=2C_=C3=A0s_9h_=28hor=C3=A1rio_de_?=
 =?utf-8?q?Bras=C3=ADlia=29=3A_Semana_de_Capacita=C3=A7=C3=A3o_-_AUTOMATIZ?=
 =?utf-8?q?A=C3=87=C3=83O_DE_AN=C3=9ANCIOS_DE_TR=C3=82NSITO_BGP_COM_COMMUN?=
 =?utf-8?q?ITIES_E_VRF_USANDO_HUAWEI_E_MIKROTIK=2E?=
Message-ID: <dd110d7f-bf82-9583-7c8f-b8ebf164f8b2@nic.br>

Ol? Pessoal,


O quarto dia da semana de capacita??o est? para come?ar. N?o percam, as 
9h (hor?rio de Bras?lia), teremos AUTOMATIZA??O DE AN?NCIOS DE TR?NSITO 
BGP COM COMMUNITIES E VRF USANDO HUAWEI E MIKROTIK. Veja a sua ementa:

- Conceitos b?sicos do Roteamento e EVE-NG
- Caracter?sticas e facilidades principais
- Comandos mais utilizados
- Conceitos b?sico de MPLS
- Conceitos b?sico de iBGP
- Conceitos b?sico de MP-BGP
- Conceitos b?sico de COMMUNITY BGP
- Porque usar VRF em Provedor
- Conceitos b?sico de VRF
- Laborat?rio de VRF
- Laborat?rio de automa??o dos An?ncios na VRF
- Troubleshooting

Palestrantes:

Lacier Da Costa Dias Junior (VLSM)
Luiz Puppin (VLSM)

Assista em https://youtu.be/Y4JJgoX96PI . Teremos certificado para quem 
acompanhar o evento ao vivo.


Abs,

Eduardo Barasal Morales


From emorales at nic.br  Fri Aug 28 08:16:00 2020
From: emorales at nic.br (Eduardo Morales)
Date: Fri, 28 Aug 2020 08:16:00 -0300
Subject: [GTER] =?utf-8?q?Daqui_a_pouco=2C_=C3=A0s_9h_=28hor=C3=A1rio_de_?=
 =?utf-8?b?QnJhc8OtbGlhKTogU2VtYW5hIGRlIENhcGFjaXRhw6fDo28gLSBFVk9MVcOH?=
 =?utf-8?q?=C3=83O_DA_TECNOLOGIA_DE_TRANSPORTE_LAYER_2_=E2=80=93_ETHERNET_?=
 =?utf-8?q?VPN=2E?=
Message-ID: <c76c5843-d30f-0ced-855f-7ca34499baf7@nic.br>

Ol? Pessoal,


O quinto dia da semana de capacita??o est? para come?ar. N?o percam, as 
9h (hor?rio de Bras?lia), teremos EVOLU??O DA TECNOLOGIA DE TRANSPORTE 
LAYER 2 ? ETHERNET VPN. Veja a sua ementa:

Neste webinar apresentaremos a evolu??o e consolida??o das tecnologias 
atuais de Layer 2 VPN ponto a ponto e multiponto para o Ethernet VPN.

Abordaremos os conceitos e terminologias do EVPN como evolu??o aos 
atuais padr?es L2VPN e VPLS, detalhando seu plano de controle BGP e 
plano de encaminhamento de dados, e discutindo um pouco das suas 
principais arquiteturas e aplica??es.

Palestrantes:

Eduardo R. Lopes de Haro (Juniper)

Assista em https://youtu.be/G06S_PTSOZk . Teremos certificado para quem 
acompanhar o evento ao vivo.


Abs,

Eduardo Barasal Morales


From bruno at openline.com.br  Fri Aug 28 09:27:37 2020
From: bruno at openline.com.br (Bruno Cabral)
Date: Fri, 28 Aug 2020 12:27:37 +0000
Subject: [GTER] bgp.he.net dando erro?
Message-ID: <CP2PR80MB36354290276E2E712A38BA6FF5520@CP2PR80MB3635.lamprd80.prod.outlook.com>

Ol?

Algu?m da HE notou que est? dando esse erro na consulta de ASs?

ASxxx has not been visible in the global routing table since August 21, 2020
The information displayed is from that time.

Grato
!3runo Cabral


From marcusgc at gmail.com  Fri Aug 28 11:38:08 2020
From: marcusgc at gmail.com (=?UTF-8?Q?Marcus_Vinicius_Gon=C3=A7alves_Cesario?=)
Date: Fri, 28 Aug 2020 11:38:08 -0300
Subject: [GTER] geolocation Globoplay
In-Reply-To: <3F5F3A5A-B8E4-48A7-9040-56BC3BE580A4@gmail.com>
References: <3F5F3A5A-B8E4-48A7-9040-56BC3BE580A4@gmail.com>
Message-ID: <CAGcabgP-RDL6NnCP4t_FVh=e=+JhsJwNrTVb5ECejjzjoP3COQ@mail.gmail.com>

On Fri, Jul 31, 2020 at 1:46 PM Epafras R Schaden <epafras.schaden at gmail.com>
wrote:

> Bom dia a todos.
>
>
>
> Alguem saberia me informar qual a base de geolocaliza??o o servi?o da
> Globoplay usa para determinar as regi?es/cidades em que o servi?o ?
> suportado ou n?o ?
>

? usada a base da Max Mind -  https://www.maxmind.com/en/home

-- 
Marcus Vinicius G. Ces?rio

From alexandre at opticalhost.com.br  Fri Aug 28 16:04:37 2020
From: alexandre at opticalhost.com.br (Alexandre Aleixo | Opticalhost)
Date: Fri, 28 Aug 2020 16:04:37 -0300
Subject: [GTER] bgp.he.net dando erro?
In-Reply-To: <CP2PR80MB36354290276E2E712A38BA6FF5520@CP2PR80MB3635.lamprd80.prod.outlook.com>
References: <CP2PR80MB36354290276E2E712A38BA6FF5520@CP2PR80MB3635.lamprd80.prod.outlook.com>
Message-ID: <CAO4k36685EYaiKV6KVNomqUVhthLvNP8bg5WOWgnh7_XSbCurQ@mail.gmail.com>

H? alguns dias havia reparado que todos os dados do bgp.he.net haviam
sumido...

Foi logo depois do bgpview.io retornar depois de dias sem acessar...

E nesse caso do bgpview, percebi que quando retornou, foi com dados zerados
(e praticamente sem exibir nada do Brasil, pelo bloqueio do whois do
RBR)...

N?o tinha reparado que os dados do bgp he estavam desatualizados... Mas vi
agora que realmente constam como ?ltima atualiza??o em 21/08...

Alexandre Aleixo



Em sex., 28 de ago. de 2020 ?s 09:27, Bruno Cabral <bruno at openline.com.br>
escreveu:

> Ol?
>
> Algu?m da HE notou que est? dando esse erro na consulta de ASs?
>
> ASxxx has not been visible in the global routing table since August 21,
> 2020
> The information displayed is from that time.
>
> Grato
> !3runo Cabral
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From fhfrediani at gmail.com  Sat Aug 29 15:03:14 2020
From: fhfrediani at gmail.com (Fernando Frediani)
Date: Sat, 29 Aug 2020 15:03:14 -0300
Subject: [GTER] Possibilidade de blocos IPv4 para ASNs
Message-ID: <522a89cf-ce44-0952-8f05-73f9446ac4db@gmail.com>

Ol? a todos
Quero aproveitar a oportunidade deste email para passar uma mensagem 
importante para a comunidade de operadores de rede Brasileira ? respeito 
deste assunto.

Ontem algumas pessoas fizeram uma brincadeira ? respeito da 
possibilidade de Sistemas Aut?nomos conseguirem mais blocos IPv4 para 
sua opera??o, mesmo ap?s a exaust?o completa da pool de endere?os IPv4 
na regi?o do LACNIC, e foi uma surpresa o n?mero at? que razo?vel de 
pessoas que se interessaram por esta possibilidade querendo saber mais ? 
respeito.

Isso n?o ? poss?vel pessoal ! Por melhor e mais bem feita que seja a 
proposta desconfie pois ? imposs?vel para qualquer Sistema Aut?nomo, por 
mais nobre que seja a justificativa de uso ou mesmo que o provedor 
esteja em franco crescimento dada a atual situa??o nenhuma empresa 
Brasileira j? detentora de recursos ir? receber mais endere?os sob 
nenhuma hip?tese.

? importante dizer isso para que pessoas n?o coloquem seu dinheiro em 
propostas como essas onde n?o h? muito o que fazer. Ao inv?s disso 
invistam esfor?os para se adaptarem a utilizar aqueles endere?os que 
atualmente possuem para fazer um CGNAT bem feito e obviamente para 
implantar IPv6 onde falta na rede.

Mesmo que outros Sistemas Aut?nomos que possuem IPv4 sobrando se 
disponham ? alugar ou "emprestar" endere?os IPv4 cuidado com isso ! N?o 
existe previs?o dessa pr?tica na regras da regi?o do LACNIC e o 
Registro.br pode facilmente entender que o detentor daqueles endere?os 
"emprestados" n?o possui mais uso para eles e iniciar processo de 
recupera??o, afinal quando qualquer Sistema Aut?nomo recebeu os recursos 
durante a justificativa ? muito improv?vel que algu?m tenha justificado 
que iria utilizar os endere?os para alugar ou emprestar para outro.

A ?nica possibilidade de obter endere?os IPv4 de acordo com as regras ? 
atrav?s das transfer?ncias, por?m este ? um processo complexo e bem caro 
para um n?mero bem reduzido de endere?os IPv4.

Espero que isso ajude ? esclarecer aqueles que ainda possuem alguma 
esperan?a ? respeito.

Fernando Frediani

From deimon.machado at gmail.com  Sat Aug 29 22:55:28 2020
From: deimon.machado at gmail.com (Deimon Machado)
Date: Sat, 29 Aug 2020 22:55:28 -0300
Subject: [GTER] Possibilidade de blocos IPv4 para ASNs
In-Reply-To: <522a89cf-ce44-0952-8f05-73f9446ac4db@gmail.com>
References: <522a89cf-ce44-0952-8f05-73f9446ac4db@gmail.com>
Message-ID: <CAADpDU8O5eYxyBOU_+Rwd7Q3=VF4Q7J3bxTmGEVnQzJYMvXVCQ@mail.gmail.com>

Excelente, esclaredor!

Grato a?!

Deimon V Machado

Em s?b, 29 de ago de 2020 15:03, Fernando Frediani <fhfrediani at gmail.com>
escreveu:

> Ol? a todos
> Quero aproveitar a oportunidade deste email para passar uma mensagem
> importante para a comunidade de operadores de rede Brasileira ? respeito
> deste assunto.
>
> Ontem algumas pessoas fizeram uma brincadeira ? respeito da
> possibilidade de Sistemas Aut?nomos conseguirem mais blocos IPv4 para
> sua opera??o, mesmo ap?s a exaust?o completa da pool de endere?os IPv4
> na regi?o do LACNIC, e foi uma surpresa o n?mero at? que razo?vel de
> pessoas que se interessaram por esta possibilidade querendo saber mais ?
> respeito.
>
> Isso n?o ? poss?vel pessoal ! Por melhor e mais bem feita que seja a
> proposta desconfie pois ? imposs?vel para qualquer Sistema Aut?nomo, por
> mais nobre que seja a justificativa de uso ou mesmo que o provedor
> esteja em franco crescimento dada a atual situa??o nenhuma empresa
> Brasileira j? detentora de recursos ir? receber mais endere?os sob
> nenhuma hip?tese.
>
> ? importante dizer isso para que pessoas n?o coloquem seu dinheiro em
> propostas como essas onde n?o h? muito o que fazer. Ao inv?s disso
> invistam esfor?os para se adaptarem a utilizar aqueles endere?os que
> atualmente possuem para fazer um CGNAT bem feito e obviamente para
> implantar IPv6 onde falta na rede.
>
> Mesmo que outros Sistemas Aut?nomos que possuem IPv4 sobrando se
> disponham ? alugar ou "emprestar" endere?os IPv4 cuidado com isso ! N?o
> existe previs?o dessa pr?tica na regras da regi?o do LACNIC e o
> Registro.br pode facilmente entender que o detentor daqueles endere?os
> "emprestados" n?o possui mais uso para eles e iniciar processo de
> recupera??o, afinal quando qualquer Sistema Aut?nomo recebeu os recursos
> durante a justificativa ? muito improv?vel que algu?m tenha justificado
> que iria utilizar os endere?os para alugar ou emprestar para outro.
>
> A ?nica possibilidade de obter endere?os IPv4 de acordo com as regras ?
> atrav?s das transfer?ncias, por?m este ? um processo complexo e bem caro
> para um n?mero bem reduzido de endere?os IPv4.
>
> Espero que isso ajude ? esclarecer aqueles que ainda possuem alguma
> esperan?a ? respeito.
>
> Fernando Frediani
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

From juliao at braga.eti.br  Mon Aug 31 12:17:51 2020
From: juliao at braga.eti.br (Juliao Braga)
Date: Mon, 31 Aug 2020 12:17:51 -0300
Subject: [GTER] Possibilidade de blocos IPv4 para ASNs
In-Reply-To: <522a89cf-ce44-0952-8f05-73f9446ac4db@gmail.com>
References: <522a89cf-ce44-0952-8f05-73f9446ac4db@gmail.com>
Message-ID: <fa219723-8571-845a-a3ad-5d39ed1dedd1@braga.eti.br>

Aproveitando a dica do Fernando adiciono alguns esclarecimentos.

Se voc? ? um provedor, mas n?o ? AS, isto ?, n?o pertence ? Internet, 
voc? pode:

a. Tirar um ASN e um bloco IPv6 (por exemplo, um enorme de um /32) e 
pagar R$2.400,00 por ano;

b. Ap?s tirar o ASN+IPv6 entrar na fila aguardar a disponibilidade de 
IPv4 vindo do reposit?rio de IPs em recupera??o (mau uso, n?o uso, 
informa??es conflitantes, etc. -> 
https://registro.br/tecnologia/numeracao/recuperacao-de-recursos/) que 
n?o conseguiram justificar. H? uma pequena e boa quantidade de IPs nesta 
situa??o (https://ftp.registro.br/pub/numeracao/recuperacao-latest).

b1. Voc? sendo o primeiro da fila, o sistema de Numera??o do Registro.br 
ir? lhe oferecer o que estiver dispon?vel (de /24 a /22). Se voc? 
aceitar recebe o recurso e sai da fila. Se n?o aceitar (um /24, p. ex.) 
continua no primeiro lugar da fila.

c. Sendo AS, voc? pode comprar alguma carteira de clientes ou empresa de 
um outro AS com recursos de IPv4 e pode tranfer?-los para seu ASN 
(https://registro.br/tecnologia/numeracao/transferencias/).

Portanto, vale a pena tirar o seu ASN e fazer parte da Internet. Seus 
clientes ir?o adorar!

[]s

Juli?o Braga, Ph.D.

Em 29/08/2020 15:03, Fernando Frediani escreveu:
> Ol? a todos
> Quero aproveitar a oportunidade deste email para passar uma mensagem 
> importante para a comunidade de operadores de rede Brasileira ? respeito 
> deste assunto.
> 
> Ontem algumas pessoas fizeram uma brincadeira ? respeito da 
> possibilidade de Sistemas Aut?nomos conseguirem mais blocos IPv4 para 
> sua opera??o, mesmo ap?s a exaust?o completa da pool de endere?os IPv4 
> na regi?o do LACNIC, e foi uma surpresa o n?mero at? que razo?vel de 
> pessoas que se interessaram por esta possibilidade querendo saber mais ? 
> respeito.
> 
> Isso n?o ? poss?vel pessoal ! Por melhor e mais bem feita que seja a 
> proposta desconfie pois ? imposs?vel para qualquer Sistema Aut?nomo, por 
> mais nobre que seja a justificativa de uso ou mesmo que o provedor 
> esteja em franco crescimento dada a atual situa??o nenhuma empresa 
> Brasileira j? detentora de recursos ir? receber mais endere?os sob 
> nenhuma hip?tese.
> 
> ? importante dizer isso para que pessoas n?o coloquem seu dinheiro em 
> propostas como essas onde n?o h? muito o que fazer. Ao inv?s disso 
> invistam esfor?os para se adaptarem a utilizar aqueles endere?os que 
> atualmente possuem para fazer um CGNAT bem feito e obviamente para 
> implantar IPv6 onde falta na rede.
> 
> Mesmo que outros Sistemas Aut?nomos que possuem IPv4 sobrando se 
> disponham ? alugar ou "emprestar" endere?os IPv4 cuidado com isso ! N?o 
> existe previs?o dessa pr?tica na regras da regi?o do LACNIC e o 
> Registro.br pode facilmente entender que o detentor daqueles endere?os 
> "emprestados" n?o possui mais uso para eles e iniciar processo de 
> recupera??o, afinal quando qualquer Sistema Aut?nomo recebeu os recursos 
> durante a justificativa ? muito improv?vel que algu?m tenha justificado 
> que iria utilizar os endere?os para alugar ou emprestar para outro.
> 
> A ?nica possibilidade de obter endere?os IPv4 de acordo com as regras ? 
> atrav?s das transfer?ncias, por?m este ? um processo complexo e bem caro 
> para um n?mero bem reduzido de endere?os IPv4.
> 
> Espero que isso ajude ? esclarecer aqueles que ainda possuem alguma 
> esperan?a ? respeito.
> 
> Fernando Frediani
> -- 
> gter list??? https://eng.registro.br/mailman/listinfo/gter

From alexandre at opticalhost.com.br  Mon Aug 31 23:35:49 2020
From: alexandre at opticalhost.com.br (Alexandre Aleixo | Opticalhost)
Date: Mon, 31 Aug 2020 23:35:49 -0300
Subject: [GTER] SACI - O que seria?
Message-ID: <CAO4k36595CE6APcCgi52MjfvgEhPJu4bQin-g9677eGf_KZJWQ@mail.gmail.com>

Pessoal, boa noite!

Os gurus da lista (em especial aqueles que batem ponto no Registro.br)
poderiam me esclarecer o que seria a informa??o "SACI - Sim" que aparece no
WHOIS de alguns dom?nios brasileiros?

Desde j? agrade?o!

Alexandre Aleixo

From rubensk at gmail.com  Mon Aug 31 23:47:54 2020
From: rubensk at gmail.com (Rubens Kuhl)
Date: Mon, 31 Aug 2020 23:47:54 -0300
Subject: [GTER] SACI - O que seria?
In-Reply-To: <CAO4k36595CE6APcCgi52MjfvgEhPJu4bQin-g9677eGf_KZJWQ@mail.gmail.com>
References: <CAO4k36595CE6APcCgi52MjfvgEhPJu4bQin-g9677eGf_KZJWQ@mail.gmail.com>
Message-ID: <CAGFn2k0mzaA_57azK6k5QbdsOx5xGEiGFSg_AY=rHJebQ7s-AQ@mail.gmail.com>

On Mon, Aug 31, 2020 at 11:36 PM Alexandre Aleixo | Opticalhost
<alexandre at opticalhost.com.br> wrote:
>
> Pessoal, boa noite!
>
> Os gurus da lista (em especial aqueles que batem ponto no Registro.br)
> poderiam me esclarecer o que seria a informa??o "SACI - Sim" que aparece no
> WHOIS de alguns dom?nios brasileiros?

Significa que ? noite o saci vem puxar o DNS do dom?nio... ;-)

Na verdade:
https://registro.br/dominio/saci-adm/

Significa que no registro desse dom?nio o titular aceitou esse
procedimento administrativo de resolu??o de disputa de propriedade
intelectual.


Rubens