[GTER] IX.BR - Route-Servers - Congratulações e HashTags

Fri Mar 18 22:33:16 -03 2022

Também sempre achei que 4 (3 também) é muita coisa, principalmente 
sabendo que cada RS não é um único servidor.

Fico no aguardo do descomissionamento dos RS 3 e 4 para baixar as sessões.

Fernando

On 17/03/2022 15:57, Andre Bolzan via gter wrote:
> @Douglas Fischer <fischerdouglas at gmail.com> sempre tiveram debates
> incriveis...
>
> Eu não sabia que algumas empresas deixavam um ou mais RS fora, porque a
> caixa não suporta número de rotas ... 1kk de rola realmente é relevante...
> Agora faz sentido porque alguns RS tem número de rotas diferentes...
>
> Sempre achei *4 RS* "exagero" , *MAS* em vez de 4, achava legal 3...
>
> Regra do "quem tem *1* não tem nenhum, tem *2* tem 1"... Afinal estamos
> falando do maior *IX *do mundo (*orgulho* em dizer isso rsrsr)
>
> MAS...  Ainda pensando na quantidade de RS no ix.BR ...
>
> Penso que os *RS *devem ser providos/hospedado por uma farm de Servidores
> em HA e talvez a possibilidade de termos só 1 rodando deve ser "mínima" ...
>
> Afinal os RS(uma máquina linux rodando BIRD) só precisa réplica "blocos" de
> RAM(tabela de rota atualizando de x em x tempo) entre os servidores para
> ter HA, não tem muito fluxo de dados em servidor, escrita em disco,
> etcs....
>
> Em caso de uma falha de hardware em algum servidor físico a farm levaria
> pouquíssimo tempo(casa de milissegundos) para outro servidor assumir o RS e
> seguirmos com 2 RS online...
>
> Tirando falhas de software/OS/operacional(pessoas) , não teríamos riscos de
> termos "apenas" 1 RS rodando, usando apenas 2 RS como "padrão" em vez de 4
> RS
>
> Porque não 2 ? Afina simplicidade nunca deixou de ser importante rsrsr
>
> Com a diminuição dos RS, temos um grande ganho, a diminuição do tamanho da
> tabela de rotas nos equipamentos, ela sairá da casas dos 1kk(quase) para
> "apenas 500k" que garantiria maior vida útil dos equipamento...
>
> Afinal a crise dos chips não deixou de ser relevante...
>
> Em qui., 17 de mar. de 2022 às 12:36, Alexandre J. Correa (Onda) via gter <
> gter at eng.registro.br> escreveu:
>
>>
>> http://docs.ix.br/doc/communities-table-ix-br-v2_0-13012022.pdf
>>
>> http://docs.ix.br/doc/politica-de-tratamento-de-communities-no-ix-br-v4_3.pdf
>>
>> Em breve acredito que vão suportar...
>>
>> Em 16/03/2022 16:58, Filho Arrais via gter escreveu:
>>> Olá,
>>>
>>> Acompanho o autor e demais colegas, são válidas as colocações e elogios.
>>>
>>> O blackhole é algo que estamos aguardando a bastante tempo, esperamos
>> que o
>>> time do IX consiga disponibilizar.
>>>
>>> Aproveitando a oportunidade, uma sugestão que se aplicada seria uma mão
>> na
>>> roda é as community por localidade . Pra quem é ITP ou utiliza ITP que
>> está
>>> conectado em múltiplas localidades, seria bem interessante poder
>> controlar
>>> os anúncios por localidade
>>>
>>> Ex em large community:
>>>
>>>      not announce to ASN - 65000:011:dest-asn (SP)
>>>      not announce to ASN - 65000:021:dest-asn (RJ)
>>>      not announce to ASN - 65000:085:dest-asn (CE)
>>>      prepend..
>>>      etc
>>>      etc
>>>
>>>
>>> Atenciosamente,
>>>
>>> Em qua., 16 de mar. de 2022 às 16:47, Elizandro Pacheco [ NextHop
>> Solutions
>>> ® ] via gter <gter at eng.registro.br> escreveu:
>>>
>>>> Blackhole no IX é uma solicitação bastante antiga. É algo que realmente
>>>> seria de grande ajuda para a internet no Brasil.
>>>>
>>>> Não sei quais as limitações reais pra implementação, mas seria ótimo se
>>>> isso fosse uma prioridade internamente.
>>>>
>>>> Todos ficaríamos felizes :)
>>>>
>>>> Elizandro Pacheco
>>>>
>>>> On 15/03/2022 14:58, Ricardo via gter wrote:
>>>>> Se a Equipe do Ix.br achar que é pancada baixar os Rs3 e Rs4,  começa
>>>>> com o Rs4 deixa 3 meses ou  6 meses e depois parte para o Rs3 se ainda
>>>>> grande parte dos participantes continuarem baixar a sessão do Rs3,
>>>>> provavelmente esses participantes que deixam as sessões do Rs3 e Rs4
>>>>> também possuem apenas uma conexão junto ao Ix.br onde o fator
>>>>> resiliência não é o essencial.
>>>>> Os 3 Rs promovem uma redundância muito maior que 2 Rs, não é apenas
>>>>> mais 1 ponto , é um ponto adicional que deverá sofrer falhas na janela
>>>>> de intervalo que os outros 2 Rs. 3 é um numero ok.
>>>>>
>>>>> 4 rotas de fibras totalmente distintas para os Pix, esses sim é numero
>>>>> que poderia subir para 8 , hehe.
>>>>>
>>>>> Referente ao RTBH , liberar um guide seguindo a linha do ix-equinix,
>>>>> bem intuitivo :
>>>>>
>>>>>
>> https://docs.equinix.com/pt-br/Content/Interconnection/IX/IX-rtbh-guide.htm
>>>>>
>>>>>
>>>>> ---
>>>>>    Atenciosamente,
>>>>> Ricardo Tessaro
>>>>> projetos at dipelnet.com.br
>>>>> 45991360228
>>>>> Cascavel - Rua Paraná, 3016
>>>>> Fone (45) 3220 2700
>>>>>
>>>>> Em 2022-03-14 20:57, Renato Ornelas via gter escreveu:
>>>>>
>>>>>> Sobre as communities, realmente quanto mais informação, melhores vão
>>>>>> ficando os nossos filtros e de uma maneira geral melhor vai ficando a
>>>>>> Internet no Brasil.
>>>>>>
>>>>>> Sobre o RS3 e RS4, também acho que não existe mais necessidade, vejo
>> em
>>>>>> muito cliente sessão para mais de um RS fora para "não afetar a
>>>>>> performance". E a rede do IX.br-SP está bem madura e tranquila (toc
>> toc
>>>>>> toc) a bom tempo, parabéns pro time!
>>>>>>
>>>>>> Atenciosamente,
>>>>>>
>>>>>> Renato Ornelas
>>>>>> OpenX - Soluções para ISPs.
>>>>>>
>>>>>> Em seg., 14 de mar. de 2022 às 10:10, Douglas Fischer via gter <
>>>>>> gter at eng.registro.br> escreveu:
>>>>>>
>>>>>> Novidades!
>>>>>>
>>>>>> Os Route-Servers de Curitiba já estão na versão 2 da metodologia do
>>>>>> IX.BR
>>>>>> https://status.ix.br/incident/804
>>>>>>
>>>>>> E temos manutenção programada referente a atualização do Route-Server
>>>>>> 2 do
>>>>>> RJ para amanhã.
>>>>>>
>>>>>> --- Segue Texto notificação ---
>>>>>> NIC.br/IX.br(PTT.br) - Manutenção do Route Server 2 de Rio de
>>>>>> Janeiro/RJ /
>>>>>> Route Server 2 maintenance - Terca/Tuesday 20220315 - 7am to 6pm
>>>>>> (UTC-3) em
>>>>>> 21 horas
>>>>>>
>>>>>> *English version bellow*
>>>>>>
>>>>>> Prezados participantes do IX.br do Rio de Janeiro,
>>>>>>
>>>>>> Na terca (15/Mar/2022) das 7h às 18h o route server 2 será atualizado
>> e
>>>>>> haverá instabilidade na sessão BGP com ele. Os ips deste route server
>>>>>> são
>>>>>> os seguintes:
>>>>>>
>>>>>> IPv4: 45.6.52.254 IPv6: 2001:12f8:0:2::52:254
>>>>>>
>>>>>> Durante este período o route server 1 continuará operando normalmente
>>>>>> e com
>>>>>> isso não ocorrerá interrupção de tráfego.
>>>>>>
>>>>>> Qualquer questão abram um chamado no portal Meu.IX.br
>>>>>> (https://meu.ix.br/
>>>>>> ),
>>>>>> ou entrem em contato com a equipe de Suporte do IX.br:
>>>>>>
>>>>>> +55 11 5509-3550 noc at ix.br
>>>>>>
>>>>>> Atenciosamente, Equipe IX.br
>>>>>> --- Fim do Texto da notificação ---
>>>>>>
>>>>>> Em qua., 16 de fev. de 2022 às 16:55, Douglas Fischer <
>>>>>> fischerdouglas at gmail.com> escreveu:
>>>>>>
>>>>>> TL;DR
>>>>>> - Maratona de atualizações de route-servers em pouco tempo e sem
>>>>>> intercorrências. -> Parabéns!
>>>>>> - Novas funcionalidades. Dedo-duro de quem está com transporte cagado
>> ->
>>>>>> Obrigado!
>>>>>> - Ainda tem route-servers em versões velhas. -> Pra quando? Sigam
>> firmes
>>>>>> e fortes! Tamo aqui pra ajudar.
>>>>>> - BlackHole, ainda faltam peças. -> Pra quando?
>>>>>> - Route Servers 3 e 4 em SP e RJ - Redundância demais ATRAPALHA! ->
>>>>>> Quando vai ser o shutdown?
>>>>>>
>>>>>> Alô galera!
>>>>>>
>>>>>> Disclaimer-> Primeiro eu vou gavar eles, e depois... depois... eu vou
>>>>>> ser
>>>>>> tão gentil quanto me é peculiar.
>>>>>>
>>>>>> Hashtags envolvidas -> #MigraTudoPraV2-0 #BlackHoleCadêVocê
>>>>>> #ShutdownRS3eRS4
>>>>>>
>>>>>> Maratona de atualizações de route-servers
>>>>>> -----------------------------------------
>>>>>> Segue abaixo a lista de atividades de atualização de route-rervers que
>>>>>> foram realizadas pela equipe do IX.BR.
>>>>>> Foram 47 atividades, que ocorreram entre 10 de janeiro e 2
>> fevereiro(23
>>>>>> dias), abrangendo 47 route-servers em 24 localidades do IX.BR.
>>>>>> Tudo isso num curto período de tempo(em minha opinião) e não
>>>>>> resultando em intercorrências. PARABÉNS!
>>>>>>
>>>>>> 10 de janeiro de 2022
>>>>>> https://status.ix.br/incident/698 - Fortaleza, CE - Route Server 2
>>>>>> https://status.ix.br/incident/699 - Caxias do Sul, CXJ - Route
>> Server 2
>>>>>> https://status.ix.br/incident/700 - Cascavel, CAC - Route Server 2
>>>>>> https://status.ix.br/incident/701 - Santa Maria, RIA - Route Server 2
>>>>>> https://status.ix.br/incident/702 - Sao Luiz, SLZ - Route Server 2
>>>>>> https://status.ix.br/incident/703 - CGB - Route Server 2
>>>>>> 12 de janeiro de 2022
>>>>>> https://status.ix.br/incident/704 - Fortaleza, CE - Route Server 1
>>>>>> https://status.ix.br/incident/705 - Caxias do Sul, CXJ - Route
>> Server 1
>>>>>> https://status.ix.br/incident/706 - Cascavel, CAC - Route Server 1
>>>>>> https://status.ix.br/incident/707 - Santa Maria, RIA - Route Server 1
>>>>>> https://status.ix.br/incident/708 - Sao Luiz, SLZ - Route Server 1
>>>>>> https://status.ix.br/incident/709 - Cuiaba, CGB - Route Server 1
>>>>>> 18 de janeiro de 2022
>>>>>> https://status.ix.br/incident/717 - Foz do Iguaçu, IGU - Route
>> Server 2
>>>>>> https://status.ix.br/incident/718 - Aracaju, SE - Route Server 2
>>>>>> https://status.ix.br/incident/719 - São José dos Campos, SJC - Route
>>>>>> Server 2
>>>>>> https://status.ix.br/incident/720 - Maringá, MGF - Route Server 2
>>>>>> https://status.ix.br/incident/721 - São José do Rio Preto, SJP -
>> Route
>>>>>> Server 2
>>>>>> https://status.ix.br/incident/722 - Belém, BEL - Route Server 2
>>>>>> 19 de janeiro de 2022
>>>>>> https://status.ix.br/incident/723 - Foz do Iguaçu, IGU - Route
>> Server 1
>>>>>> https://status.ix.br/incident/724 - Aracaju, SE - Route Server 1
>>>>>> https://status.ix.br/incident/725 - São José dos Campos, SJC - Route
>>>>>> Server 1
>>>>>> https://status.ix.br/incident/726 - Maringá, MGF - Route Server 1
>>>>>> https://status.ix.br/incident/727 - São José do Rio Preto, SJP -
>> Route
>>>>>> Server 1
>>>>>> https://status.ix.br/incident/728 - Belém, BEL - Route Server 1
>>>>>> 24 de janeiro de 2022
>>>>>> https://status.ix.br/incident/733 - Campo Grande, CGR - Route Server
>> 2
>>>>>> https://status.ix.br/incident/734 - Maceió, MCZ - Route Server 2
>>>>>> https://status.ix.br/incident/735 - Campina Grande, CPV - Route
>> Server
>>>> 2
>>>>>> https://status.ix.br/incident/736 - Londrina, LDA - Route Server 2
>>>>>> https://status.ix.br/incident/737 - Natal, NAT - Route Server 2
>>>>>> https://status.ix.br/incident/738 - Teresina, THE - Route Server 2
>>>>>> https://status.ix.br/incident/739 - Lajeado, LAJ - Route Server 2
>>>>>> https://status.ix.br/incident/740 - João Pessoa, JPA - Route Server 2
>>>>>> https://status.ix.br/incident/741 - Recife, PE - Route Server 2
>>>>>> https://status.ix.br/incident/742 - Manaus, MAO - Route Server 2
>>>>>> https://status.ix.br/incident/743 - Goiania, GYN - Route Server 2
>>>>>> 26 de janeiro de 2022
>>>>>> https://status.ix.br/incident/747 - Campo Grande, CGR - Route Server
>> 1
>>>>>> https://status.ix.br/incident/748 - Maceió, MCZ - Route Server 1
>>>>>> https://status.ix.br/incident/749 - Campina Grande, CPV - Route
>> Server
>>>> 1
>>>>>> https://status.ix.br/incident/750 - Londrina, LDA   - Route Server 1
>>>>>> https://status.ix.br/incident/751 - Natal, NAT - Route Server 1
>>>>>> https://status.ix.br/incident/752 - Teresina, THE - Route Server 1
>>>>>> https://status.ix.br/incident/753 - Lajeado, LAJ - Route Server 1
>>>>>> https://status.ix.br/incident/754 - João Pessoa, JPA - Route Server 1
>>>>>> https://status.ix.br/incident/755 - Recife, PE - Route Server 1
>>>>>> https://status.ix.br/incident/756 - Manaus, MAO - Route Server 1
>>>>>> https://status.ix.br/incident/757 - Goiania, GYN - Route Server 1
>>>>>> 2 de fevereiro de 2022
>>>>>> https://status.ix.br/incident/772 - Vitória/ES / Route Server 2
>>>>>> (Obs.: Se não me engano, R1 de Vitória tinha sido o Beta-Test dessa
>> nova
>>>>>> versão. Atualizado ainda no ano passado.)
>>>>>>
>>>>>> Novas funcionalidades
>>>>>> ---------------------------
>>>>>>
>>>>>> Pelo que pude saber, essas manutenções atualizaram a versão da engine
>>>>>> BGP
>>>>>> para o BIRD 2.0.8, e implementaram uma série de novas funcionalidades
>> e
>>>>>> communities nessas localidades, incluindo:
>>>>>> Communities informativas e de engenharia de tráfego para:
>>>>>> - Classificar os Peers com base na latência entre o Route-Server os
>>>>>> routers.
>>>>>> [Ou seja, se o teu router lá na casa do chapéu, os coleguinhas vão
>>>>>> poder saber disso por community BGP, e escolher não trocar tráfego
>>>>>> contigo por causa disso.]
>>>>>> - Classificar os Peers com base nas perdas quantidades de perdas de
>>>>>> pacotes nos horários de maior demanda do IXP.
>>>>>> [Ou seja, se você é um pouca-prática e contratou um serviço porcaria
>> de
>>>>>> transporte, ou é um muquirana e contrata menos capacidade do que
>>>>>> realmente precisa, os coleguinhas vão poder saber disso por community
>>>>>> BGP, e escolher não trocar tráfego conigo por causa disso.]
>>>>>> - Ter o suporte a funcionalidade de BlackHole do IXP sendo tratada na
>>>>>> camada do Route-Server
>>>>>> [Filtrar, limpar as cagadas, e mudar o next-hop para um IP que estará
>>>>>> amarrado num MAC-Address com uma ACL de bloqueio na entrada da malha
>>>>>> do IXP] As características funcionais dessa nova versão de
>>>>>> Route-Server do IX.BR
>>>>>> estão descritas no seguinte documento:
>>>>>>
>>>>>>
>> http://docs.ix.br/doc/politica-de-tratamento-de-communities-no-ix-br-v4_3.pdf
>>>>>> Bueno...
>>>>>> Até aqui eu estava dando os parabéns e reconhecendo o trabalho fora de
>>>>>> série que esses cabras fazem.
>>>>>> Eles tem minha admiração!
>>>>>>
>>>>>> Mas, como "nem tudo na vida são flores!", vamos logo para o
>> FORROBODÓ...
>>>>>> Ainda tem route-servers em versões velhas
>>>>>> -------------------------------------------------------
>>>>>> A lista a seguir é das localidades que, segundo pude consultar no
>>>>>> http://lg.ix.br/ , ainda não receberam a atualização para a nova
>> versão
>>>>>> de Route-Server do IX.BR.
>>>>>> - salvador.ba.ix.br -> bird 1.6.3
>>>>>> - portoalegre.rs.ix.br -> bird 1.6.3
>>>>>> - curitiba.pr.ix.br  ->  bird 1.6.3
>>>>>> - brasilia.df.ix.br  ->  bird 1.6.3
>>>>>> -  belohorizonte.mg.ix.br  ->  bird 1.6.3
>>>>>> -  riodejaneiro.rj.ix.br  ->  bird 1.6.3
>>>>>> -  saopaulo.rj.ix.br  ->  multibird 2.0.2
>>>>>> E sendo assim, pelo que pode ser entendido nas informações divulgadas
>> em
>>>>>> https://ix.br/documentacao/ , isso implica que nessas localidades
>> ainda
>>>>>> não estão disponíveis muitas das funcionalidades cidatas no documento
>> de
>>>>>> nova versão de route-serve do IX.BR
>>>>>>
>>>>>> Vamos a primeira perguntinha desconfortável:
>>>>>> -> E aí controle da missão? Podem compartilhar as previsões de data
>> para
>>>>>> as atualizações desses route-servers?
>>>>>> -> Especialmente São Paulo...
>>>>>>
>>>>>> #MigraTudoPraV2-0
>>>>>> Se eu gostasse de mi-mi-mi eu comprava um gato gago!
>>>>>> E sempre aparece um sem noção reclamando das atualizações e fazendo
>>>>>> mi-mi-mi por causa de indisponibilidade...
>>>>>> Bom... Só posso falar por mim. Mas eu DUVIDO que quem aparece para
>>>>>> reclamar e pedir para não atualizar sejam as empresas que estejam com
>>>>>> tudo redondinho.
>>>>>> Então, se tiver algum coleguinha revoltoso precisando de gentileza e
>>>>>> carinho para ser convencido a parar de reclamar das manutenções
>>>>>> PREVENTIVAS... Podem contar comigo!
>>>>>>
>>>>>> Lembram da #BlackHoleNoIX.BR ?
>>>>>> -----------------------------------------------
>>>>>> No IX Fórum de dezembro de 2021 foi anunciado que as localidades do
>>>>>> IX.BR passariam gradativamente a suportar o serviço de BlackHole.
>>>>>> E o modelo escolhido(acertadamente, em minha opinião) foi aquele que
>>>>>> depende 4 componentes:
>>>>>> A - Route-Server aceitar, fazer validações, remarcar communities, e
>>>>>> reenviar para os demais participantes os prefixos anunciados como
>>>>>> BlackHole por cada participante.
>>>>>> B - Ativação de um host com o IPs de black hole na rede LAN de cada
>> uma
>>>>>> das localidades, sendo que Mac-Address da resolução ARP e ND desse
>>>>>> host é
>>>>>> que seria a base do drop.
>>>>>> C - Implementação de filtros em ACL de Layer2 que bloqueariam todo
>>>>>> pacote enviado por qualquer participante com Mac-Address de destino
>>>>>> desse
>>>>>> host de blackhole.
>>>>>> D - Participantes ajustarem suas regras de filtragem de rotas para com
>>>>>> os Route-Servers para aceitar as rotas /32 e /128 com a community de
>>>>>> blackhole.
>>>>>>
>>>>>> Pelo que me consta, a barreira do item A está sendo vencida com as
>>>>>> atualizações de versão de route-servers.
>>>>>>
>>>>>> As próximas perguntinhas desconfortáveis:
>>>>>> -> Esses hosts de IP de blackhole já foram ativados em quais
>>>>>> localidades?  -> As ACLs de Layer2 já foram implementadas em quais
>>>>>> localidades? Existe
>>>>>> algum obstrutor para isso acontecer?
>>>>>> Agora a perguntinha mais chata!
>>>>>> -> E as mudanças necessárias nos filtros de BGP dos milhares de
>>>>>> participantes do IX.BR? Como vai ser garantido isso?
>>>>>> -> Já foi criada alguma notificação oficial sobre como deve ser a
>>>>>> configuração de filtros BGP no lado do participante para suportar
>>>>>> adequadamente esse recurso de blackhole?
>>>>>> [Caso queiram, será um prazer para nós da comunidade criarmos
>>>>>> colaborativamente esse material.]
>>>>>> -> Já foi cogitado/desenhado/implementado algum mecanismo que permia
>>>>>> algum tipo de automação na verificação dessas configurações de
>>>>>> filtros BGP validando aceite correto de blackhole?
>>>>>>
>>>>>> #BlackHoleCadêVocê
>>>>>> Essa é para sintetizar essas questões acima relacionadas aos
>> componentes
>>>>>> necessários para o funcionamento de #BlackHoleNoIX.BR
>>>>>>
>>>>>> Route Servers 3 e 4 em SP e RJ
>>>>>> -------------------------------------------
>>>>>>
>>>>>> Deixei o melhor para o final!
>>>>>> Quem acompanhou a história de crescimento do IX.BR certamente lembra
>>>> das
>>>>>> dores que passamos todos com instabilidades com os route-servers pois
>> na
>>>>>> época não exisita nada viável técnica e financeiramente que
>> conseguisse
>>>>>> aguentar tantos peers e tantas rotas.
>>>>>> E ciente disso é possível afirmar que para aquela época, com os
>> recursos
>>>>>> que existiam no momento, ter mais 2 route-server FOI a solução mais
>>>>>> acertada.
>>>>>>
>>>>>> Porém, diante do pouquinho que conheço do lado das redes
>>>>>> participantes, e
>>>>>> do que posso imaginar na realidade do IX.BR eu me atrevoa a afirmar:
>>>>>> HOJE, com os recursos e soluções atuais, a existência de 4(quatro)
>>>>>> route-servers ao invés de 2(dois) não está aumentando disponibilidade
>>>>>> e só está gerando atrapalhos!
>>>>>>
>>>>>> Existem os atrapalhos do ponto de vista da operação do IX.BR.
>>>>>> Eu poderia exemplificar com: Mais hardwares para manter e monitorar,
>>>>>> mais
>>>>>> sessões para manter e monitorar, mais energia, mais software para
>> manter
>>>>>> atualizado, mais arquivos de configuração para revisar, etc etc etc...
>>>>>> Mas como aprendi com um amigo, isso é uma dor auto-inflingida,
>> escolhas
>>>>>> deles próprios trazendo dores para eles mesmos.
>>>>>> Portanto é algo a ser considerado POR ELES.
>>>>>>
>>>>>> Mas existem os atrapalhos que afetam a operação das redes dos
>>>>>> participantes do IX.BR!
>>>>>> E que atrapalhos são esses?
>>>>>> Falando só de IPv4, no IX.BR-SP hoje temos aproximadamente 280 mil
>> rotas
>>>>>> em cada route-server. Com 4 Route-Servers isso dá ~1,1 MILHÃO de
>> rotas!
>>>>>> Mais que um Full-Routing de alguma Tier1.
>>>>>> Como fator agravante, infelizmente até agora o BIRD não possui
>>>>>> recursos de MRAI (Item 9.2.1.1 da RFC 4721) e RFD (RFC 2439), o que
>>>>>> faz com que a média de BGP Updade-Messages por rota seja muito mais
>>>>>> alta que em qualquer outro peer.
>>>>>> Isso custa capacidade computacional do roteador! Isso consome
>> capacidade
>>>>>> da RIB do roteador!
>>>>>>
>>>>>> Agora é que vem a cereja do bolo:
>>>>>> Como essas 8 sessões(4xIPv4 + 4xIPv6) realmente impactam a
>>>>>> performance de
>>>>>> grande parte dos equipamentos ligados ao IX.BR-SP, os coleguinhas
>>>>>> excedem o limite da criatividade e começam a transcender o limite do
>>>>>> razoável. Os
>>>>>> caras saem baixando as sessões com os IXPs redundantes na loucura.
>>>>>> O problema é que uns gênios resolvem baixar RS1, RS2, RS3. E outros
>>>>>> gênios resolvem baixar RS2, RS3, RS4. E com isso acaba que esses dois
>>>>>> 'J'ênios do exemplo acabam não trocando rotas entre-si. (E esse é
>>>>>> apenas um dos
>>>>>> exemplos dos causos que conhecemos.)
>>>>>>
>>>>>> Se estivesse tudo certinho, o certo seria dar uma tunda de pau nesses
>>>>>> 'J'ênios que eu mencionei que deixam as sessões com alguns dos
>>>>>> Route-Server derrubadas.
>>>>>> Mas pelo outro lado, o problema que os 4 route-servers trazem é real!
>>>>>>
>>>>>> #ShutdownRS3eRS4
>>>>>> Essa é a para que em breve a gente possa começar a zoar os
>>>>>> coleguinhas que deixam sessões com route-servers down com maior
>>>>>> propriedade.
>>>>>>
>>>>>> Bom... Acho que era isso!
>>>>>> Existe muitos outros tópicos, mas esse e-mail aqui já ficou mais
>>>>>> comprido
>>>>>> que a abertura de Game of Thrones.
>>>>>>
>>>>>> Aaaaaa. Se por acaso eu ofendi alguém:
>>>>>> DEPENDE!
>>>>>> Se você suas ações e posturas se encaixam no perfil de quem merece ser
>>>>>> ofendido, mantenho o que disse!
>>>>>> Se for alguma palavra mal colocada, peço desculpas.
>>>>>>
>>>>>> --
>>>>>> 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
>>>> --
>>>> 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
>>
>