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

Andre Bolzan andre.bolzan at fixfibra.com.br
Mon Apr 11 15:21:35 -03 2022 

@Douglas Fischer <fischerdouglas at gmail.com> Missão comprida !

Obrigado a todos os envolvidos ! Cada contribuição foi importante para
melhor internet do Brasil !


Anuncio oficial:

Prezados participantes do IX.br de São Paulo/SP,

No dia 18/04/2022(próxima segunda) às 8 da manhã os route servers 3 e 4
serão desativados e passaremos a operar permanentemente com apenas os route
servers 1 e 2, sendo assim, por favor, desativem a sessão BGP com os route
servers 3 e 4.

Os ips dos route servers que serão desativados são os seguintes:

RS3:
 - IPv4: 187.16.223.253
 - IPv6: 2001:12f8::223:253

RS4:
 - IPv4: 187.16.223.254
 - IPv6: 2001:12f8::223:254

Em sex., 18 de mar. de 2022 às 22:33, Fernando Frediani via gter <
gter at eng.registro.br> escreveu:

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


-- 

*André Bolzan Saar*

*Services Delivery*
*+55 11 98205-7742*

More information about the gter mailing list