[GTER] Segestao de RFC
Mauro Lucio Silva
maurolucio.silva at gmail.com
Mon Dec 11 18:33:38 -02 2017
Uma solução para o seu caso sem ter que realizar nehuma solicitação ao
IETF é utilizar endereços da RFC-7793 100.64.0.0/10. está faixa já foi
designada para este proposito.
2017-12-11 12:09 GMT-02:00 <gter-request at eng.registro.br>:
> Send gter mailing list submissions to
> gter at eng.registro.br
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://eng.registro.br/mailman/listinfo/gter
> or, via email, send a message with subject or body 'help' to
> gter-request at eng.registro.br
>
> You can reach the person managing the list at
> gter-owner at eng.registro.br
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gter digest..."
>
> Today's Topics:
>
> 1. Re: Segestao de RFC (Douglas Fischer)
> 2. Re: Segestao de RFC (Junior Corazza)
> 3. CDNs (Paulo Losqui)
> 4. Re: Brocade vRouter - ServerU L800 (Leonardo Amaral - Listas)
>
>
> ---------- Mensagem encaminhada ----------
> From: Douglas Fischer <fischerdouglas at gmail.com>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>
> Cc:
> Bcc:
> Date: Mon, 11 Dec 2017 11:21:44 -0200
> Subject: Re: [GTER] Segestao de RFC
> Aquele e-mailzinho maroto para o contato de roteamento do ASN dizendo:
>
> "Hey dona operadora... Tudo Bão cocêis?
> Estou tentando entregar determinada aplicação para meu cliente passando por
> cima da infra de vocês.
> Mas quando os pacotes de minha aplicação passas pelo salto com IP
> 123.123.123.123 o problema "TAL" acontece."
>
>
>
> Em 11 de dezembro de 2017 10:14, Andre Almeida <andre at bnet.com.br> escreveu:
>
>> Essa técnica deve ser só pra poder usar DNS reverso..... não?
>>
>> Qual é o sentido de ter um IP roteável em local não roteável?
>>
>> Andre
>>
>> Em 11 de dezembro de 2017 09:53, Douglas Fischer <fischerdouglas at gmail.com
>> >
>> escreveu:
>>
>> > Acabei de me lembrar que tem operadoras que usam Blocos IP válidos na
>> > Internet, porém não colocam ele na DFZ(não divulgam esse bloco). Um
>> exemplo
>> > é a Level3.
>> >
>> > É uma técnica meio controversa, mas que faz algum sentido...
>> >
>> > Ele usam esses IPs válidos nas redes de Enlace, mas estão "escondidos"
>> > embaixo de uma camada de MPLS.
>> > E pelo que sei eles além de esses IPs não estarem divulgados para a
>> > Internet(DFZ), eles estão numa VRF específica de gerenciamento e essa VRF
>> > está toda atrás de firewall.
>> >
>> >
>> >
>> > Ou seja:
>> > Tens que ter MUITA consideração com os aspectos de segurança.
>> >
>> >
>> >
>> > Em 11 de dezembro de 2017 09:44, Douglas Fischer <
>> fischerdouglas at gmail.com
>> > >
>> > escreveu:
>> >
>> > > Você também citou como suposta vantagem o fato de a rede de enlace com
>> a
>> > > operadora que lhe provê trânsito não ser alcançável da Internet.
>> > >
>> > > Bom, num possível ataque isso é realmente uma vantagem.
>> > >
>> > > Mas vale lembrar que exitem muitos pontos que tornam essa técnica
>> > > negativa...
>> > > Um exemplo é quanto existem alguma falha de roteamento caótica em nosso
>> > > ASN e temos que lançar mão da vergonhosa e porquissima técnica de NAT
>> em
>> > > cima do IP da WAN da Operadora.
>> > >
>> > >
>> > >
>> > >
>> > > Em 11 de dezembro de 2017 07:52, Junior Corazza <corazza at incert.com.br
>> >
>> > > escreveu:
>> > >
>> > >> Conforme disse em minha apresentação na GTER44, em alguns provedores
>> que
>> > >> faco consultoria devido a falta de endereços IPs para o acesso resolvi
>> > >> substituir todos os IPs publicos do backbone para IPs privados da
>> > rfc1918.
>> > >> Com isso ganho alguns endereços para que sejam aplicados no acesso de
>> > >> clientes.
>> > >>
>> > >> Essa pratica nao eh nova e ja eh utilizada por muitos, mas encontrei
>> > >> alguns
>> > >> problemas utilizando esses IPs e nao achei nenhum outro documento que
>> > >> defina
>> > >> um bloco pra isso.
>> > >>
>> > >> Por isso gostaria de montar um grupo para submetermos ao IETF uma
>> DRAFT
>> > de
>> > >> RFC para que possamos delegar um bloco especifico para essa aplicacao,
>> > >> tendo
>> > >> em vista que ja temos varias outras RFCs que delegam blocos para usos
>> > >> específicos nao creio que seja uma tarefa dificil
>> > >>
>> > >>
>> > >>
>> > >> Aceito ideias, criticas e pessoas que se disponham a ajudar no
>> projeto.
>> > >>
>> > >>
>> > >>
>> > >> __
>> > >>
>> > >> Junior Corazza
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> 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
>> > --
>> > 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
>
>
>
> ---------- Mensagem encaminhada ----------
> From: Junior Corazza <corazza at incert.com.br>
> To: <gter at eng.registro.br>
> Cc:
> Bcc:
> Date: Mon, 11 Dec 2017 11:22:09 -0200
> Subject: Re: [GTER] Segestao de RFC
> ? Outro ponto a ser discutido sobre seu DRAFT ?, como reservar um bloco
> dedicado para este tipo de servi?o, tendo em falta IPs no mercado. Vale
> lembrar que a RFC teria ?mbito mundial.
> - No começo eu dei a ideia de quebrar os blocos da RFC2544 em dois /16 já
> que é usa RFC com pouco uso, outra opção eh o bloco 128.66.0.0/16 que pelo
> que me parece ainda não tem seu uso muito bem definido.
>
> ? Pensando no aspecto v6, poder?amos adotar um BEST PRACTICE, adotando um
> bloco dentro do range disponibilizado, dedicado apenas a isso o que tornaria
> mais r?pido e f?cil um throubleshooting. Visando um aspecto v4, acredito ser
> uma discuss?o que vai dar id?ias mas sem muitos resultados.
> - Otima ideia.
>
> Aumento de TTL, tuneis MPLS e outras coisas do tipo resolve o problema do
> icmp, mas e o conflito na entrega de servicos?
>
> Pensei em utilizar o bloco de CGNAT para fazer essa interligacao e fugir do
> conflito, mas seria pisar em outra RFC.
>
>
>
>
>
> -----Mensagem original-----
> De: gter [mailto:gter-bounces at eng.registro.br] Em nome de
> gter-request at eng.registro.br
> Enviada em: segunda-feira, 11 de dezembro de 2017 09:50
> Para: gter at eng.registro.br
> Assunto: gter Digest, Vol 177, Issue 17
>
> Send gter mailing list submissions to
> gter at eng.registro.br
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://eng.registro.br/mailman/listinfo/gter
> or, via email, send a message with subject or body 'help' to
> gter-request at eng.registro.br
>
> You can reach the person managing the list at
> gter-owner at eng.registro.br
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of gter digest..."
>
>
> Today's Topics:
>
> 1. RES: CGNAT - Aonde colocar? (Junior Corazza)
> 2. Segestao de RFC (Junior Corazza)
> 3. Re: Segestao de RFC (Jefferson Gondek)
> 4. Re: Segestao de RFC (Bruno Cabral)
> 5. Re: Segestao de RFC (Danton Nunes)
> 6. Re: Segestao de RFC (Douglas Fischer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 10 Dec 2017 12:30:14 -0200
> From: "Junior Corazza" <corazza at incert.com.br>
> To: <gter at eng.registro.br>
> Subject: [GTER] RES: CGNAT - Aonde colocar?
> Message-ID: <000001d371c3$66e15080$34a3f180$@incert.com.br>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Talvez eu tenha me expressado errado.
>
> Eu faco o CGNAT na mesma caixa onde eu rodo o PPPoE server, ou seja, CE
> PPPoE.
> Na CPE do cliente fa?o o NAT.
>
>
> Message: 1
> Date: Sat, 9 Dec 2017 12:14:52 -0200
> From: <rafael at rafaelduarte.eti.br>
> To: "'Grupo de Trabalho de Engenharia e Operacao de Redes'"
> <gter at eng.registro.br>
> Subject: [GTER] RES: CGNAT - Aonde colocar?
> Message-ID:
>
> <!&!AAAAAAAAAAAuAAAAAAAAALy2QqjpRHRHr/WMwksPL28BAMO2jhD3dRHOtM0AqgC7tuYAAAAA
> AA4AABAAAABE4XOz4+xtQJbub92R+TAcAQAAAAA=@rafaelduarte.eti.br>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> CE = Customer Edge ?
>
> Voc? faz o NAT para a rede do Cliente, mas em algum roteador da sua infra
> voc? precisa fazer o CGNAT e n?o no roteador do cliente.
>
> Acho que voc? confundiu, nat com cgnat
>
> Att
> Rafael A. Duarte
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 11 Dec 2017 07:52:45 -0200
> From: "Junior Corazza" <corazza at incert.com.br>
> To: <gter at eng.registro.br>
> Subject: [GTER] Segestao de RFC
> Message-ID: <002c01d37265$cd2f7860$678e6920$@incert.com.br>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Conforme disse em minha apresenta??o na GTER44, em alguns provedores que
> faco consultoria devido a falta de endere?os IPs para o acesso resolvi
> substituir todos os IPs publicos do backbone para IPs privados da rfc1918.
> Com isso ganho alguns endere?os para que sejam aplicados no acesso de
> clientes.
>
> Essa pratica nao eh nova e ja eh utilizada por muitos, mas encontrei alguns
> problemas utilizando esses IPs e nao achei nenhum outro documento que defina
> um bloco pra isso.
>
> Por isso gostaria de montar um grupo para submetermos ao IETF uma DRAFT de
> RFC para que possamos delegar um bloco especifico para essa aplicacao, tendo
> em vista que ja temos varias outras RFCs que delegam blocos para usos
> espec?ficos nao creio que seja uma tarefa dificil
>
>
>
> Aceito ideias, criticas e pessoas que se disponham a ajudar no projeto.
>
>
>
> __
>
> Junior Corazza
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 11 Dec 2017 09:17:54 -0200
> From: Jefferson Gondek <jefferson.gondek at iveloz.net.br>
> To: gter at eng.registro.br
> Subject: Re: [GTER] Segestao de RFC
> Message-ID: <dcefa432-f8c6-f523-20f6-07aa805848e7 at iveloz.net.br>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Bom dia Junior,
>
> ? Acho a iniciativa muito v?lida, mas com alguns pontos a serem discutidos.
>
> ? Aqui tentamos adotar essa pr?tica, mas os peers BGP n?o se deram muito
> bem com o uso de IPs da RFC1918.
>
> ? Outro ponto a ser discutido sobre seu DRAFT ?, como reservar um bloco
> dedicado para este tipo de servi?o, tendo em falta IPs no mercado. Vale
> lembrar que a RFC teria ?mbito mundial.
>
> ? Pensando no aspecto v6, poder?amos adotar um BEST PRACTICE, adotando um
> bloco dentro do range disponibilizado, dedicado apenas a isso o que tornaria
> mais r?pido e f?cil um throubleshooting. Visando um aspecto v4, acredito ser
> uma discuss?o que vai dar id?ias mas sem muitos resultados.
> Mas como diria o ditado: "Uma andorinha n?o faz ver?o...", vamos ver o que
> os demais tem em mente.
>
> Acompanhando a discuss?o aqui.....
>
> Abra?os.
>
> Jefferson
>
>
> Em 11/12/2017 07:52, Junior Corazza escreveu:
>> Conforme disse em minha apresenta??o na GTER44, em alguns provedores
>> que faco consultoria devido a falta de endere?os IPs para o acesso
>> resolvi substituir todos os IPs publicos do backbone para IPs privados da
> rfc1918.
>> Com isso ganho alguns endere?os para que sejam aplicados no acesso de
>> clientes.
>>
>> Essa pratica nao eh nova e ja eh utilizada por muitos, mas encontrei
>> alguns problemas utilizando esses IPs e nao achei nenhum outro
>> documento que defina um bloco pra isso.
>>
>> Por isso gostaria de montar um grupo para submetermos ao IETF uma
>> DRAFT de RFC para que possamos delegar um bloco especifico para essa
>> aplicacao, tendo em vista que ja temos varias outras RFCs que delegam
>> blocos para usos espec?ficos nao creio que seja uma tarefa dificil
>>
>>
>>
>> Aceito ideias, criticas e pessoas que se disponham a ajudar no projeto.
>>
>>
>>
>> __
>>
>> Junior Corazza
>>
>>
>>
>> --
>> gter list https://eng.registro.br/mailman/listinfo/gter
>>
>
> --
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 11 Dec 2017 11:24:23 +0000
> From: Bruno Cabral <bruno at openline.com.br>
> To: "jefferson.gondek at iveloz.net.br" <jefferson.gondek at iveloz.net.br>,
> "Grupo de Trabalho de Engenharia e Operacao de Redes"
> <gter at eng.registro.br>
> Subject: Re: [GTER] Segestao de RFC
> Message-ID:
>
> <RO1PR80MB052255B6D529080CF261102CF5370 at RO1PR80MB0522.lamprd80.prod.outlook.
> com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Se o problema foi nas conexoes saintes a partir do roteador, nada que um NAT
> do IP privado nao resolva
>
>
> Outra coisa que pode ser feita ? um aumento no TTL dos pacotes, "escondendo"
> o IP do roteador
>
>
> !3runo
>
>
> --
> Cursos e Consultoria BGP e OSPF
> ________________________________
> De: gter <gter-bounces at eng.registro.br> em nome de Jefferson Gondek
> <jefferson.gondek at iveloz.net.br>
> Enviado: segunda-feira, 11 de dezembro de 2017 09:17:54
> Para: gter at eng.registro.br
> Assunto: Re: [GTER] Segestao de RFC
>
> Bom dia Junior,
>
> Acho a iniciativa muito v?lida, mas com alguns pontos a serem discutidos.
>
> Aqui tentamos adotar essa pr?tica, mas os peers BGP n?o se deram muito
> bem com o uso de IPs da RFC1918.
>
> Outro ponto a ser discutido sobre seu DRAFT ?, como reservar um bloco
> dedicado para este tipo de servi?o, tendo em falta IPs no mercado. Vale
> lembrar que a RFC teria ?mbito mundial.
>
> Pensando no aspecto v6, poder?amos adotar um BEST PRACTICE, adotando um
> bloco dentro do range disponibilizado, dedicado apenas a isso o que tornaria
> mais r?pido e f?cil um throubleshooting. Visando um aspecto v4, acredito ser
> uma discuss?o que vai dar id?ias mas sem muitos resultados.
> Mas como diria o ditado: "Uma andorinha n?o faz ver?o...", vamos ver o que
> os demais tem em mente.
>
> Acompanhando a discuss?o aqui.....
>
> Abra?os.
>
> Jefferson
>
>
> Em 11/12/2017 07:52, Junior Corazza escreveu:
>> Conforme disse em minha apresenta??o na GTER44, em alguns provedores
>> que faco consultoria devido a falta de endere?os IPs para o acesso
>> resolvi substituir todos os IPs publicos do backbone para IPs privados da
> rfc1918.
>> Com isso ganho alguns endere?os para que sejam aplicados no acesso de
>> clientes.
>>
>> Essa pratica nao eh nova e ja eh utilizada por muitos, mas encontrei
>> alguns problemas utilizando esses IPs e nao achei nenhum outro
>> documento que defina um bloco pra isso.
>>
>> Por isso gostaria de montar um grupo para submetermos ao IETF uma
>> DRAFT de RFC para que possamos delegar um bloco especifico para essa
>> aplicacao, tendo em vista que ja temos varias outras RFCs que delegam
>> blocos para usos espec?ficos nao creio que seja uma tarefa dificil
>>
>>
>>
>> Aceito ideias, criticas e pessoas que se disponham a ajudar no projeto.
>>
>>
>>
>> __
>>
>> Junior Corazza
>>
>>
>>
>> --
>> gter list https://eng.registro.br/mailman/listinfo/gter
>>
>
> --
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 11 Dec 2017 09:22:00 -0200 (-02)
> From: Danton Nunes <danton.nunes at inexo.com.br>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>
> Subject: Re: [GTER] Segestao de RFC
> Message-ID: <alpine.DEB.2.20.1712110902500.31399 at zaphod>
> Content-Type: text/plain; charset=iso-8859-1; format=flowed
>
> On Mon, 11 Dec 2017, Junior Corazza wrote:
>
>> Conforme disse em minha apresenta??o na GTER44, em alguns provedores
>> que faco consultoria devido a falta de endere?os IPs para o acesso
>> resolvi substituir todos os IPs publicos do backbone para IPs privados da
> rfc1918.
>> Com isso ganho alguns endere?os para que sejam aplicados no acesso de
>> clientes.
>>
>> Essa pratica nao eh nova e ja eh utilizada por muitos, mas encontrei
>> alguns problemas utilizando esses IPs e nao achei nenhum outro
>> documento que defina um bloco pra isso.
>
> o principal problema, como Rubens bem notou durante tua apresenta??o, ? o
> endere?o de retorno de mensagens ICMP, que n?o ser? rote?vel.
>
> creio que o uso de interfaces 'unnumbered' resolveria esse problema pois as
> mensagens ICMP viriam com o endere?o da interface referenciada (normalmente
> loopback ou algum ethernet).
>
>> Por isso gostaria de montar um grupo para submetermos ao IETF uma
>> DRAFT de RFC para que possamos delegar um bloco especifico para essa
>> aplicacao, tendo em vista que ja temos varias outras RFCs que delegam
>> blocos para usos espec?ficos nao creio que seja uma tarefa dificil
>
> fica a pergunta, ser? que n?o seria trocar seis por meia d?zia? esse novo
> bloco, que voc? at? sugeriu qual seria, seria t?o pouco rote?vel quanto os
> blocos da BCP-5 (aka RFC-1918). para que fossem rote?veis seria necess?rio
> uma autoridade (RIR?) que delegasse os endere?os do bloco para que fossem
> ?nicos, e que fossem anunciados pelo BGP. N?o creio que um bloco /16 teria
> essas caracter?sticas.
>
> se for para ficar sem as mensagens do ICMP ent?o n?o h? porque n?o usar os
> endere?os BCP-5.
>
> enquanto voltava para casa na Vila Mariana, espremido como sardinha em lata
> no trem da CPTM, pintou uma ideia simples: porque n?o fazer todo o
> encaminhamento da central ao cliente em n?vel 2 (ou dois e meio no caso),
> sem usar qualquer endere?o IP, atrav?s de uma malha MPLS. Do ponto de vista
> de IP a malha toda viraria um ?nico salto e n?o seriam necess?rios endere?os
> IP nos roteadores intermedi?rios (ou poderiam ser endere?os BCP-5, ou ainda
> IPv6, completamente invis?veis para o mundo externo). Al?m disso MPLS
> permite fazer alguma engenharia de tr?fego, tipo controle de banda, e
> encaminhamento din?mico para aproveitar caminhos redundantes.
>
> -- Danton
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 11 Dec 2017 09:39:03 -0200
> From: Douglas Fischer <fischerdouglas at gmail.com>
> To: Jefferson Gondek <jefferson.gondek at iveloz.net.br>, Grupo de
> Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>
> Subject: Re: [GTER] Segestao de RFC
> Message-ID:
> <CAKEr4RR81CoGQz-F2yLUGihJfmjN4HNuWyjwYo9695krEhuwsQ at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Al?m do Bloco espec?fico para isso, existem outras quest?es que voc? deve se
> preocupar nesse draft.
>
> Tens que definir t?cnicas que permitam que pacotes como o que o Rubens Kuhl
> mencionou completem suas tarefas...
> - "Packet too Big", relacionado a fragmenta??o
> - "TTL Expired", usado nos traceroutes e tamb?m e caso de loops de
> roteamento.
> E por a? vai...
>
> Algumas t?cnicas v?lidas:
> - Em cada Router, ter um /32(ou /128) v?lido na DFZ definido numa loopback
> Configurar o Router para que toda resposta de ICMP(e similares) saia dessa
> interface.
> - Usar uma sub-rede delimitada para isso Ex.: 10.X.X.X/20.
> Definir um IP v?lido para usar para as respostas de todos esses pacotes de
> controle
> Fazer um SRC-NAT perto da borda dizendo "Se vier de dentro da minha rede,
> sendo dessa faixa, maqueie usando esse /32"
> - Uma outra t?cnica seria colocar todo teu backbone em cima de um MPLS, e
> esconder os TTL-Decrements.
> Essa inclusive ? uma t?cnica usada por v?rias operadora, onde posso citar
> a Oi e a antiga Telef?nica(para o servi?o de VPN-L3).
>
>
>
> Em 11 de dezembro de 2017 09:17, Jefferson Gondek <
> jefferson.gondek at iveloz.net.br> escreveu:
>
>> Bom dia Junior,
>>
>> Acho a iniciativa muito v?lida, mas com alguns pontos a serem
> discutidos.
>>
>> Aqui tentamos adotar essa pr?tica, mas os peers BGP n?o se deram
>> muito bem com o uso de IPs da RFC1918.
>>
>> Outro ponto a ser discutido sobre seu DRAFT ?, como reservar um
>> bloco dedicado para este tipo de servi?o, tendo em falta IPs no
>> mercado. Vale lembrar que a RFC teria ?mbito mundial.
>>
>> Pensando no aspecto v6, poder?amos adotar um BEST PRACTICE, adotando
>> um bloco dentro do range disponibilizado, dedicado apenas a isso o que
>> tornaria mais r?pido e f?cil um throubleshooting. Visando um aspecto
>> v4, acredito ser uma discuss?o que vai dar id?ias mas sem muitos
> resultados.
>> Mas como diria o ditado: "Uma andorinha n?o faz ver?o...", vamos ver o
>> que os demais tem em mente.
>>
>> Acompanhando a discuss?o aqui.....
>>
>> Abra?os.
>>
>> Jefferson
>>
>>
>>
>> Em 11/12/2017 07:52, Junior Corazza escreveu:
>>
>>> Conforme disse em minha apresenta??o na GTER44, em alguns provedores
>>> que faco consultoria devido a falta de endere?os IPs para o acesso
>>> resolvi substituir todos os IPs publicos do backbone para IPs privados da
> rfc1918.
>>> Com isso ganho alguns endere?os para que sejam aplicados no acesso de
>>> clientes.
>>>
>>> Essa pratica nao eh nova e ja eh utilizada por muitos, mas encontrei
>>> alguns problemas utilizando esses IPs e nao achei nenhum outro
>>> documento que defina um bloco pra isso.
>>>
>>> Por isso gostaria de montar um grupo para submetermos ao IETF uma
>>> DRAFT de RFC para que possamos delegar um bloco especifico para essa
>>> aplicacao, tendo em vista que ja temos varias outras RFCs que delegam
>>> blocos para usos espec?ficos nao creio que seja uma tarefa dificil
>>>
>>>
>>> Aceito ideias, criticas e pessoas que se disponham a ajudar no projeto.
>>>
>>>
>>> __
>>>
>>> Junior Corazza
>>>
>>>
>>> --
>>> 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
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> gter digest list https://eng.registro.br/mailman/listinfo/gter
>
>
> ------------------------------
>
> End of gter Digest, Vol 177, Issue 17
> *************************************
>
>
>
>
>
> ---------- Mensagem encaminhada ----------
> From: Paulo Losqui <cgr at speednettelecom.com.br>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>
> Cc:
> Bcc:
> Date: Mon, 11 Dec 2017 11:32:42 -0200
> Subject: [GTER] CDNs
> Prezados,
>
>
>
> Algum de vocês sabem a quantidade de banda para adquirir os CDNs abaixo.
>
>
>
> NETFLIX=2GB
>
> GOOGLE=?
>
> AKAMAI?
>
> FACEBOOK?
>
>
>
> Att.
>
> Paulo Losqui
>
> Gerente CGR/Speednet Telecom
>
> 31-2576-0101 / 31-97308-7799
>
>
>
>
>
>
> ---------- Mensagem encaminhada ----------
> From: Leonardo Amaral - Listas <listas at leonardoamaral.com.br>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>
> Cc:
> Bcc:
> Date: Mon, 11 Dec 2017 11:35:33 -0200
> Subject: Re: [GTER] Brocade vRouter - ServerU L800
>>
>> Sim aí o jeito é partir pra um Juniper mesmo. Aqui nós colocamos um
>> Juniper de borda.
>> Ou tentar um Dell porreta com interfaces já de 40GbE da Mellanox rodando
>> um FreeBSD.
>>
>
> O FreeBSD já tem stack pra roteamento + ipfw direto com netmap? Ando por
> fora disso.
>
>
>
> [image: --]
>
> Leonardo Amaral
> [image: https://]about.me/leonardo.amaral
> <https://about.me/leonardo.amaral?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>
>
> Em 11 de dezembro de 2017 10:27, Marcelo Gondim <gondim at bsdinfo.com.br>
> escreveu:
>
>> Em 06/12/2017 09:24, Marcos Vinícius escreveu:
>>
>>> Então Gondim, ele ainda aguenta mais um tempo, mas vamos aumentar muito
>>> aqui o consumo, e vai chegar no limite do limite rsrs
>>>
>>> Ai no caso eu já estava procurando outra solução sabe. No caso pensei no
>>> vRouter, mas pelo que vi ele não é mais comercializado. Você conhece
>>> alguma
>>> solução semelhante? Se não houver, o jeito é ir para um Juniper ou algo do
>>> tipo né...
>>>
>> Sim aí o jeito é partir pra um Juniper mesmo. Aqui nós colocamos um
>> Juniper de borda.
>> Ou tentar um Dell porreta com interfaces já de 40GbE da Mellanox rodando
>> um FreeBSD.
>>
>>
>>
>>> Em 5 de dezembro de 2017 18:33, Marcelo Gondim <gondim at bsdinfo.com.br>
>>> escreveu:
>>>
>>> Em 05/12/2017 15:13, Marcos Vinícius escreveu:
>>>>
>>>> Ae Gondim, já estive contigo num curso na FreeBSD Brasil hehehe
>>>>>
>>>>> kkkkk isso aí :)
>>>>
>>>>
>>>> Aqui ta dando quase 6.0 Gbit de trafego agregado
>>>>> O que fizemos aqui foi só cpu affinity mesmo.
>>>>>
>>>>> O load aqui tá:
>>>>>
>>>>> last pid: 21390; load averages: 3.58, 3.34,
>>>>> 3.27
>>>>> up 296+22:19:08 15:12:24
>>>>> 329 processes: 14 running, 260 sleeping, 55 waiting
>>>>> CPU 0: 0.0% user, 0.0% nice, 0.0% system, 42.1% interrupt, 57.9% idle
>>>>> CPU 1: 0.0% user, 0.0% nice, 0.0% system, 47.4% interrupt, 52.6% idle
>>>>> CPU 2: 0.0% user, 0.0% nice, 0.0% system, 36.8% interrupt, 63.2% idle
>>>>> CPU 3: 0.0% user, 0.0% nice, 0.0% system, 52.6% interrupt, 47.4% idle
>>>>> CPU 4: 0.0% user, 0.0% nice, 0.0% system, 36.8% interrupt, 63.2% idle
>>>>> CPU 5: 0.0% user, 0.0% nice, 0.0% system, 52.6% interrupt, 47.4% idle
>>>>> CPU 6: 0.0% user, 0.0% nice, 0.0% system, 36.8% interrupt, 63.2% idle
>>>>> CPU 7: 0.0% user, 0.0% nice, 5.3% system, 47.4% interrupt, 47.4% idle
>>>>> Mem: 55M Active, 196M Inact, 3588M Wired, 140K Cache, 70M Free
>>>>> ARC: 2839M Total, 309M MFU, 2104M MRU, 16K Anon, 18M Header, 408M Other
>>>>> Swap: 2048M Total, 2048M Free
>>>>>
>>>>> Então a L800 foi trabalhada pra 5Gbps pelo que soube mas estou olhando
>>>> seu
>>>> load e tá tranquilo. Esse load que você colocou aí em cima é no horário
>>>> de
>>>> pico?
>>>> Se for tá bem pacas. O meu aqui é um Dell R720 e estou com tráfego com
>>>> quase 6Gbps e o load tá um pouco maior que o seu mas eu ainda coloco umas
>>>> regras de ipfw. Só não pode colocar o pf que senão o load dobra
>>>> praticamente.
>>>> Aqui o pf tá disable: pfctl -d
>>>> Mas pelo que to vendo o L800 ainda tem um chão ainda. :)
>>>>
>>>> O meu nesse horário tá assim:
>>>>
>>>> last pid: 858; load averages: 3.81, 3.85, 3.89 up 53+03:32:37
>>>> 18:26:27
>>>> 28 processes: 1 running, 27 sleeping
>>>> CPU 0: 0.0% user, 0.0% nice, 3.4% system, 32.3% interrupt, 64.3% idle
>>>> CPU 1: 0.0% user, 0.0% nice, 0.8% system, 36.5% interrupt, 62.7% idle
>>>> CPU 2: 0.0% user, 0.0% nice, 0.4% system, 23.2% interrupt, 76.4% idle
>>>> CPU 3: 0.0% user, 0.0% nice, 0.8% system, 30.0% interrupt, 69.2% idle
>>>> CPU 4: 0.0% user, 0.0% nice, 0.0% system, 28.1% interrupt, 71.9% idle
>>>> CPU 5: 0.0% user, 0.0% nice, 0.0% system, 34.6% interrupt, 65.4% idle
>>>> CPU 6: 0.0% user, 0.0% nice, 0.4% system, 30.4% interrupt, 69.2% idle
>>>> CPU 7: 0.0% user, 0.0% nice, 0.0% system, 30.4% interrupt, 69.6% idle
>>>> CPU 8: 0.0% user, 0.0% nice, 1.1% system, 37.3% interrupt, 61.6% idle
>>>> CPU 9: 0.0% user, 0.0% nice, 0.0% system, 40.7% interrupt, 59.3% idle
>>>> CPU 10: 0.0% user, 0.0% nice, 0.8% system, 43.7% interrupt, 55.5% idle
>>>> CPU 11: 0.0% user, 0.0% nice, 0.0% system, 46.4% interrupt, 53.6% idle
>>>> Mem: 6336K Active, 8820M Inact, 2508M Wired, 1533M Buf, 4560M Free
>>>> Swap: 7807M Total, 7807M Free
>>>>
>>>> E tipo as minhas interfaces são Intel X520-SR2 que não trabalham bem com
>>>> pps. Estou esperando chegar as minhas chelsios pra trocar. Aí deve ficar
>>>> melhor.
>>>>
>>>> PPS nesse momento com tráfego de 4.2Gbps de down.
>>>>
>>>> # netstat -ihw 1
>>>> input (Total) output
>>>> packets errs idrops bytes packets errs bytes colls
>>>> 705k 0 0 584M 705k 0 583M 0
>>>> 713k 0 0 592M 713k 0 592M 0
>>>> 723k 0 0 600M 722k 0 600M 0
>>>> 712k 0 0 587M 712k 0 586M 0
>>>> 714k 0 0 585M 714k 0 585M 0
>>>> 702k 0 0 571M 702k 0 571M 0
>>>> 705k 0 0 577M 705k 0 577M 0
>>>>
>>>>
>>>>
>>>>
>>>> Em 5 de dezembro de 2017 10:38, Marcelo Gondim <gondim at bsdinfo.com.br>
>>>>
>>>>> escreveu:
>>>>>
>>>>> Em 04/12/2017 15:43, Marcos Vinícius escreveu:
>>>>>
>>>>>> Bom dia!
>>>>>>
>>>>>>> Alguém tem experiencia, ou utiliza o vRouter no SeverU L800 ?
>>>>>>>
>>>>>>> Qual a licença está sendo utilizada, para quantos cores? E qual a
>>>>>>> performance de rede tem sido alcançada?
>>>>>>>
>>>>>>> Estou com um L800 aqui rodando FreeBSD (Bird - OSPF e BGP) mas já está
>>>>>>> chegando no limite, mesmo com cpu affinity.
>>>>>>>
>>>>>>> Agradeço pela atenção!
>>>>>>>
>>>>>>>
>>>>>>> *Att,*
>>>>>>> *Marcos Vinicius*
>>>>>>> --
>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>>>>>>>
>>>>>>> Bom dia Marcos,
>>>>>>>
>>>>>> Qual o tráfego que você tem hoje no pico e pps?
>>>>>>
>>>>>> Como que tá o load do equipamento? Tem uns tunings que as vezes melhora
>>>>>> bastante.
>>>>>>
>>>>>> []´s
>>>>>>
>>>>>> Gondim
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>> 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 digest list https://eng.registro.br/mailman/listinfo/gter
>
--
[]s
Mauro Lúcio
Se você for enviar esta mensagem para alguém, por favor:
1. Apague o MEU ENDEREÇO eletrônico e demais dados pessoais;
2. Encaminhe como cco (Cópia oculta) aos seus destinatários;
3. Apague também as listas de mails que estiverem abaixo do seu;
Essa é uma atitude de que preservará o endereço de todos, evitando tantos
vírus e spams na internet.
More information about the gter
mailing list