[GTER] Opiniões sobre o RouterOS v7

Thu May 19 10:48:18 -03 2022

Pois é, isso é um tipo de offload, porém ainda via software, uma vez que 
em conceito o que essa função fará, será um RIB/FIB lookup c/ algum 
cache adicional implementado, de modo que na maior parte do tempo o 
tráfego irá diretamente para os respectivos MACs/Interfaces sem precisar 
de muitos recursos de CPU pra isso. (É muito melhor do que ter o pacote 
atravessando toda a network stack desnecessariamente, poderia comportar 
regras raw ? Poderia, mas daí tem o impacto do locking/synchronization 
entre os cores/threads e regras, sem contar o tempo necessario entre 
pacotes que vão dar match na primeira regra e na última regra, que 
também iriam fazer a performance variar).

On 19/05/2022 10:30, Douglas Fischer wrote:
> Interessante saber disso...
>
> Eu enxergava o FastPath como um Hardware OffLoad de pobre.
> E por isso imaginava que se não fossem muitas regras RAW poderiam ser 
> processadas nesse hardware offload.
>
> Aprendi mais uma.
>
>
> Em qui., 19 de mai. de 2022 às 10:26, Fred Pedrisa [HyperFilter DDoS 
> Protection Solutions] via gter <gter at eng.registro.br> escreveu:
>
>     A questão do FastPath, é que basicamente isso seria outro nome para
>     "Kernel Bypass", basicamente, o tráfego "bypassa" a maior parte do
>     kernel, então nesse caso, sequer, vai para camada raw/prerouting, é
>     praticamente um "atalho mesmo", só usando a RIB/FIB, isso de tirar as
>     regras do Firewall é apenas para deixar a pessoa ciente do que está
>     acontecendo, mas na verdade, nem seria necessário. Ela poderia ter
>     uma
>     checkbox pra habilitar/desabilitar o Fastpath, sabendo das
>     vantagens/desvantagens do procedimento...
>
>     On 19/05/2022 10:20, Douglas Fischer via gter wrote:
>     > Complementação sobre o FastPath.
>     > A parte mais complicada de usar FastPath é que tem que ZERAR tudo de
>     > Firewall e deixar a caixa arreganhada.
>     >
>     > Bem que esses caras poderiam pelo menos fazer algo do tipo:
>     > "Fast-Path ficará ativo até 15 Rules RAW"
>     > Regras RAW não precisa de lookup em contrack, e poderia ser
>     calculado
>     > diretamente lá na NIC.
>     >
>     >
>     > Em qua., 18 de mai. de 2022 às 16:59, Douglas Fischer <
>     > fischerdouglas at gmail.com> 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 listhttps://eng.registro.br/mailman/listinfo/gter
>     <http://eng.registro.br/mailman/listinfo/gter>
>     >>>
>     >>
>     >> --
>     >> Douglas Fernando Fischer
>     >> Engº de Controle e Automação
>     >>
>     >
>     -- 
>     *Fred Pedrisa - CEO/CTO*
>     HyperFilter DDoS Protection Solutions <https://www.hyperfilter.com>
>     A FNXTEC, Company.
>     *Mobile:* +55 (11) 97177-7000
>     --
>     gter list https://eng.registro.br/mailman/listinfo/gter
>
>
>
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação
-- 
*Fred Pedrisa - CEO/CTO*
HyperFilter DDoS Protection Solutions <https://www.hyperfilter.com>
A FNXTEC, Company.
*Mobile:* +55 (11) 97177-7000