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

[Douglas Fischer]

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