[GTER] Boas Praticas - Router de Borda

[Lucas Willian Bocchi]

Pessoal.
Sigam a regra do KISS (Keep It Simple, <corte>). Em nenhum dos
provedores que dou suporte, enfrentei este problema, por que lá adotei
a simples política de
1) Mudar as portas padrões dos serviços
2) Criar algumas regras para limitar o acesso de fora da rede desses
equipamentos

Sei que não é a melhor solução (tem ótimas aqui, a melhor é a de rede
de gerência, etc) mas não perdi nem uma noite de sono, nem eu, nem
meus clientes, com estes problemas. A única coisa que cobrei de alguns
deles foi que atualizem os firmwares assim que possível para não terem
problemas futuros.



Em 28 de maio de 2016 11:35, Flavio Rescia Dias
<flavioresciadias at gmail.com> escreveu:
> Pessoal,
>
> Excelente thread, tanto tecnicamente, sobre experiência e humildade.
>
> Voltando, aos topicos de boas práticas, poderiamos até em pensar em
> compilar tudo isso em uma cartilha/serie de videos.
>
> Outros itens:
> - Base de usuário de gerenciamento centralizadas sempre que possível (AAA
> melhor ainda);
> - Política e Ambiente de homologação, principalmente para atualização de
> firmware (um pouco na contramão dos apressadinhos);
> On May 28, 2016 9:05 AM, "Henrique de Moraes Holschuh" <hmh at hmh.eng.br>
> wrote:
>
>> On Fri, 27 May 2016, Douglas Fischer wrote:
>> > 2016-05-27 12:38 GMT-03:00 Henrique de Moraes Holschuh <hmh at hmh.eng.br>:
>> > > On Fri, 27 May 2016, Douglas Fischer wrote:
>> > > > Mas que seria bem lindo a possibilidade de um Control-Plane
>> serapado, com
>> > > > direito a VRF de gerência, seria! NÉ?
>> > >
>> > > A capacidade de implementar isto existe via network namespaces, mas
>> teria
>> > > que ser feito na unha.  Boa sorte.
>> >
>> > Não tenho certeza se eu sei do que você está falando...
>> > - É diferente do VRF / Routing Mark?
>>
>> Network namespaces é o VRF do Linux kernel, falei sobre eles muito tempo
>> atrás numa GTER, não lembro mais qual.  Cada namespace suas próprias
>> interfaces de rede, e tabelas de roteamento.  Parece uma VM.
>>
>> Se for o Linux kernel quem está encaminhando/roteando os pacotes, é a forma
>> certa de se implementar VRFs "de verdade" (que isolam *tudo*) sem ter que
>> apelar para VMs.  Quem usa "containers" conhece bem esses namespaces.
>>
>> Agora, se a caixa tem o plano de dados fora do kernel de alguma forma (ver
>> "Cumulus Linux" e "switchd" para o exemplo típico onde se empurra o plano
>> de
>> dados para um ASIC), não é o kernel quem está encaminhando ou roteando
>> pacote no plano de dados, e network namespaces não se aplicam.
>>
>> > Tá falando de ir lá no linux?
>>
>> Sim.
>>
>> > O RouterOS tem open v-switch nativo?
>>
>> Não sei, e desconfio seriamente que estou mais feliz não sabendo...  até
>> onde sei, há o risco do RouterOS ter re-implementado todo o plano de dados
>> em userspace.  Explicaria muita coisa (isso não é um elogio).  Considero
>> pouco provável, entretanto.
>>
>> > P.S.: Como ficou evidente, conheço pouco do aspecto construtivo do
>> RouterOS.
>>
>> Quando você olha dentro do abismo por tempo demais, corre o risco dele
>> olhar
>> de volta para você, e te tragar para as profundezas.
>>
>> Por essas e por outras, evito lidar com coisas que considero uma afronta a
>> tudo que é bom e belo nesse mundo...
>>
>> --
>>   "One disk to rule them all, One disk to find them. One disk to bring
>>   them all and in the darkness grind them. In the Land of Redmond
>>   where the shadows lie." -- The Silicon Valley Tarot
>>   Henrique Holschuh
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter