[GTER] Opiniões sobre o RouterOS v7

[Douglas Fischer]

Cumprindo a promessa de complementar
Eu quero ratificar a parte que o André colocou sobre o trabalho que a
Mikrotik fez na Versão 7 com o BGP.

P.S.: Cabe reiterar que ainda acho que Mikrotik é bom para algumas coisas e
uma MERDA para outras coisas!
Que é um equipamento que tem um limite de entrega bem inferior quando
comparado com Hardware Based.
Mas que pelo quanto ele custa, se não fizerem merda na configuração, PARA
ALGUMAS COISAS, ele vai funcionar muito bem.


O BGP na V7 ficou muito bom em diversos aspectos!

- BGP não é mais monocore, e ficou MUITO RÁPIDO.
O Multithread implementado ainda não é o ideal, pois não é um multithread
verdadeiro, mas uma CCR consegue sim receber E FILTRAR um Full-Routing em
menos de 2 minutos (que é uma medida que eu tenho na MINHA CABEÇA como
razoável) ou até bem menos que isso.
E se as definições de Peer group estiverem feitas de uma forma coerente,
você vai poder ter duas Full-Routing convergindo ao mesmo tempo com quase
nada de diferença no tempo de convergência.

Um realce para o "E FILTRAR" na frase acima.
Uma das coisas que aumentava MUITO o processamento do BGP na v6 eram
filtros muito complexos.
E com isso surgiam as ABERRAÇÕES de gente deixando sessões quase sem
filtros.
Pelo que testei, a complexidade do filtro tem pouco impacto no tempo de
convergência.

"Aiiin Douglas, porque você diz que não é um multithread verdadeiro?"
Só olhar a documentação deles e ver que o affinity de thread é(por padrão)
feito com base nos peer groups, e separando em IN e OUT.
Ou seja, se você tiver 10 peers num mesmo grupo de OUT, quando chegar uma
rota nova na FIB, ela vai ser processada pelo mesmo core para ser noticiada
para esses 10 peers.
Vale lembrar que isso é exatamente o motivo pelo qual os Peer Groups foram
definidos em RFC.

P.S.: Não! Peer group não é só para dar um nominho pro peer e podar dar
clear na sessão pelo nome ao invés do IP.
Criar um peer-group para cada peer não é correto! (Que venham os flames!)

- A nova sintaxe de filtragem do BGP é excelente!
Pra mim, de longe, a sintaxe mais poderosa de filtragem de engines BGP
usados para Fowarding mesmo é a do BIRD(EXABGP não conta aqui...).
O que você pode fazer por exemplo compondo a definição de uma Community
usando variáveis diversas como o Peer-AS é fantástico.
Só consegui fazer algo parecido com isso no FRR, mas não com Route-Map, e
sim usando LUA, o que foi bem complicado pra mim.

Ainda não tive a oportunidade de operar uma rede complexa a quente com BGP
nessa nova sintaxe do Rosv7, mas os IFs e SETs dela me parecem permitir
fazer chover nas definições de todos os atributos.

- Na v7 tiveram vários problemas e alguns já corrigiram.
Exemplos?
A parte de BGP Roles tava toda cagada, e parece que tá funcionando certinho
agora.
Antes não tinha como ver as rotas que haviam sido exportadas, agora tem
mais de um método para conseguir isso(Habilitando Cache de exported, e
guardando em arquivo o Dump da sessão TCP)


"Douglas, e você recomenda usar a V7?"
Rapaiz, se eu pudesse eu recomendaria não usar mikrotik... hahaha
Mas já queé essa a pergunta, vamos lá:

> Eu NÃO RECOMENDARIA pra ninguém que dependa exclusivamente de um router
usar a v7.

> Mas se você tiver a disponibilidade de TESTAR EM PRODUÇÃO(me torceu as
bolas escrever isso) um cenário muito pequeno e com quase zero de impacto
para sua rede se precisar desligar ele completamente. E também estiver
MUITO CURIOSO. Aí acho que paga a pena testar.
Exemplos de cenário de pouco impacto?
Se você tiver 2 x 1036 como B-RAS operando FOLGADAS... Talvez valha a pena
colocar um terceiro, mas num primeiro momento isolando sem compartilhar o
barramento.
Se você tiver duas abordagens ao IX.BR, e uma delas completamente
folgada... Talvez valha a pena ver como vai rolar.
Mas só faça isso se você TIVER CONHECIMENTO para fazer diagnóstico avançado
e correção!

Sobre as versões?
7.1 é vergonhosa.
7.2 melhorou, mas falta features funcionais primordiais.
Hoje, 19/05/222, eu iria de 7.3beta40, mas APENAS COMO TESTE.


Em qua., 18 de mai. de 2022 às 20:28, Andre Bolzan <
andre.bolzan at fixfibra.com.br> escreveu:

> TARDE !
>
>
>
> Vamos são 2 perguntinhas “capciosas” ...
>
>
>
> 1) Falar de BGP ...
>
> Rodamos a versão RouterOS v7 em 'ambiente teste'... Subimos sessão entre
> NE8000(com PTT e full route) e uma 1009 com V7..
>
>
>
> Testamos BGP por pura “curiosidade”, rodamos pouco mais de 1 Giga(emulado
> via iperf )  por uns 30 dias, nada de anormal aconteceu com BGP...
>
>
>
> A v7 "realmente cumpre" oque promete com relação ao BGP "full route",
> realmente corrigiram problema de software, agora consegue usar mais de 1
> core
>
>
>
> Ainda falta um pouco de desempenho, comparado com outros softRouter, pois
> a memória RAM das CCR ainda são "simples" para BGP...
>
> Agora que a Mikrotik conseguiu resolver software, acredito que eles
> provavelmente devem lançar algum hardware mais "parrudo" para ter
> desempenho mais condizentes com o mercado.
>
> Sobre a versão 7 em “si”, Tivemos alguns  bugs em outros protocolos (OSPF
> não sumariza rotas e não tem suporte a SR-IOV) oque impossibilitou de
> seguir com mais testes com a v7.
>
>
> Não colocaria V7 em produção, a menos que seja imprescindível, você ganha
> BGP e "perde OSPF" e ganha outros 'bugs" ...
>
>
>
> Sobre a V7 que posso falar
>
>
>
> 2) opções de hardware que você sugeriu:
>
>
>
> Não iria de CCR2004-16G-2S, pois ela só tem 4 Core de 1.7Ghz(6.8 Ghz), ela
> não passa mais de 4/5 Gb , pois o datashet não fala de ASICs.
>
>
>
> A CCR2004-16G-2S me parece um produto pensado para ser um “concentrador”
> que vai rodar teste de 1Gb sem gargalo.
> A CCR2004-16G-2S  corrigindo “buraco” das 1016 e 1036 sem porta de 10G que
> anda “sobrando no mercado” ...
>
>
>
> A 1036 infelizmente é "única" opção da família mikrotik para borda, na
> casa dos 10 mil cruzeiro velho, com NF, ela tem porta e CPU para tocar sua
> carga de trabalho até seus 7/8 gibas...
>
> Outra opção é subir um softRouter(Vyos, FRR, etc) com hardware x86/virtual
> vai entregar “mais” recursos/desempenho com a mesma faixa de preço, mas vai
> você gastar mais energia(conta de luz não está fácil) e vai precisar de
> outro conhecimento além de redes para poder tocar esse ambiente
> “x86/virtual”.
>
>
>
> <InsaneMode>
>
> Sugestão “nº 20”... Se seu fornecedor de link for outro provedor
> regional.. Vê se ele consegue assumir a carga L3 da borda, você fica
> somente com Swith L2 no provedor, famoso “emprestar VS” para você. Tem
> varios “BO” para resolver nesse tipo de contrato, mas é uma opção válida
> que tem ganho força na crise dos chips rsrsr
>
> </InsaneMode>
>
> Em qua., 18 de mai. de 2022 às 17:00, Douglas Fischer via gter <
> gter at eng.registro.br> escreveu:
>
>> Aooba Luiz!
>>
>> Muitos já sabem que não morro de amores pela Mikrotik.
>> MAAAAS, eu tive que aprender a conviver com ele.
>>
>> O que posso falar muito superficialmente sobre o teu cenário é:
>> 1 - Não recomendo ir para a v7 ainda para esse teu cenário.
>> (Depois enviarei um outro e-mail compartilhando minha visão sobre isso.)
>>
>> 2 - Com uma boa dose trakitanagem na escolha de rotas(sem full-routing),
>> Fast Path ativado, e poucas rotas no IGP, essa 1009 dá e sobra pra esses 2
>> Gbps.
>>
>> Vou tentar detalhar de trás pra frente:
>> - Evite muitas rotas de IGP (OSPF) no teu border. O Mínimo possível!
>> Prum cenário com 2Gbps de banda passante, se tiver mais de 30 rotas OSPF é
>> provável que tenha que rever esse plano de numeração e sumarização.
>> - Fast-Path Ativado!
>> Esse aqui é polêmico hein... Estilo o vídeo dos "mamilos". Principalmente
>> numa 1009.
>> Mas se você conseguir cumprir TODOS os requisitos[1] do Fast Path, ele vai
>> fazer com que os pacotes não tenham que passar pela CPU para serem
>> encaminhados. Ou seja, entra por uma NIC e sai pela outra.
>> Só esse tópico já renderia uma imensa novela, mas pensando que grosso do
>> teu Download estaria vindo pelas Interfaces de 1Gbps e indo pra de 10Gbps,
>> você não sofreria com assimetria de velocidades e buffer.
>> - Escolha de rotas MAROTA
>> Quanto mais rotas na RIB/FIB mais a CCR sofre, então tem que fazer uns
>> malabarismos para tirar rotas da RIB/FIB. Como?
>> Vai ter dois Links de trânsito? Aceita a Default dos dois, e escolhe as
>> melhores rotas de cada um e rejeita todo o resto.
>> Se os seus provedores de trânsito forem empresa TOP, vão te dar
>> communities
>> para você fazer um match na community e escolher o que presta.
>> Se for provedor de trânsito feito a facão, faz um REGEX de AS-PATH e é o
>> melhor que vai conseguir.
>>
>> [1] https://wiki.mikrotik.com/wiki/Manual:Fast_Path#IPv4_handler
>>
>> Em ter., 17 de mai. de 2022 às 16:39, Luiz Filipe Silva Lopes via gter <
>> gter at eng.registro.br> escreveu:
>>
>> > Saudações, gostaria de tirar uma dúvida com os ISPs e a galera da TI:
>> >
>> > Um contexto geral para a pergunta:
>> >
>> > Aqui no meu provedor tem uma CCR1009-7G-1C-1S+ fazendo o BGP passando
>> > seus 2GB sem nenhum problema, porém eu gostaria de aumentar meu segundo
>> > link, que é de 1GB para 2GB e assim eu teria 4GB.
>> >
>> > Fiz uma breve pesquisa e encontrei duas opções para o meu caso:
>> > - CCR1036-8G-2S+
>> > - CCR2004-16G-2S+
>> >
>> > Outro detalhe, já existe versões stable do RouterOS v7 mas eu nunca tive
>> > coragem de testar elas nos roteadores em produção, especialmente em um
>> > lugar tão sensível que é o BGP.
>> >
>> > Ai eu tenho duas alternativas para escolher:
>> >
>> > 1. Eu fico com a CCR2004 e, enquanto não houver uma versão long-term do
>> > RouterOS v7, eu fico com a 6.43.16
>> >
>> > 2. Eu pego a CCR1036, coloco a versão stable da v7 e tento aproveitar
>> > todos os 36 núcleos para BGP e quem sabe sonhar com um full routing
>> > nela.
>> >
>> > Alguém ai já usa ou teve alguma experiência com a RouterOS v7 em BGP?
>> >
>> > --
>> > Atte.,
>> > Luiz Filipe
>> > Portal Link Telecom
>> > --
>> > 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
>>
>
>
> --
>
> *André Bolzan Saar*
>
> *Services Delivery*
> *+55 11 98205-7742*
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação