[GTER] Tuneis ICMP

[Lucas Willian Bocchi]

Em 17 de julho de 2012 12:30, Henrique de Moraes Holschuh <
henrique.holschuh at ima.sp.gov.br> escreveu:

> On 16-07-2012 17:35, Lucas Willian Bocchi wrote:
>
>> Em 16 de julho de 2012 17:06, Henrique de Moraes Holschuh
>> <henrique.holschuh at ima.sp.gov.**br <henrique.holschuh at ima.sp.gov.br>>
>>  escreveu:
>>
>>> On 16-07-2012 10:20, Lucas Willian Bocchi wrote:
>>>
>>>>
>>>> Nos meus roteadores linux, criei um wrapper com libcap e C pra
>>>> encher o payload de pacotes com 0. Vamos ver se funciona.
>>>>
>>>
>>>
>>> Mexer no payload de certos ICMPs vai fazer com que alguns OS os
>>> ignore.
>>>
>> Certamente, mas já havia previsto isso. Tentei fazer um controle
>> para que os pacotes válidos de alguns SO's passem pelo wrapper
>> livres. Só quando detecto um excesso de pacotes icmp de uma
>> determinada direção para a outra que o software começa atuar. Até
>> agora está bem, veremos se haverá reclamações.
>>
>
> Essa parte você não havia descrito.

Perdão, foi erro não ter citado isso.


>
>
>  Não é mágica que faz o OS conseguir relacionar um ICMP recebido com
>>> uma sessão TCP ou UDP ativa: é o payload do ICMP que permite isso.
>>>
>> Justamente por este motivo que deixo passar as mensagens de controle
>> ICMP fora dos controles de banda. Quando um ICMP por acaso cai num
>> taildrop da vida há a retransmissão, e às vezes é um PORT
>> UNREACHABLE que chega ou alguma outra mensagem que vá fazer com que o
>> sistema pare de transmitir / receber naquela porta ou envie um FIN
>> para a outra ponta.
>>
>
> Isto é resolvido com priorização e algum AQM que preste.  Tail-drop é
> praticamente a pior disciplina de controle de fila que existe...
> principalmente com fila longa.
>
Concordo que tail-drop não é a melhor política de tráfego, porém, é a que
consome menos recurso computacional.

>
> Se quiser tentar resolver o "drop do pacote errado" de verdade e o
> bufferbloat causado pelas filas longas (resolver isso resulta num enorme
> ganho de usabilidade percebido por qualquer usuário de enlace que
> costuma lotar), tente usar a disciplina codel_fq para controlar as
> bandas de prioridade de tráfego bulk.
>


> O ruim é que codel_fq só está disponível no OpenWRT de desenvolvimento,
> no Linux kernel 3.5, ou em algum backport (deve ser possível fazer um
> backport para Linux kernel 3.2.  Para mais antigo, não faço ideia).
> Para outros sistemas operacionais, não sei se alguém se habilitou a
> escrever ainda (o algorítimo é novo, tem uns poucos meses de
> existência... um dos inventores dele é o Van Jacobson)

Já havia ouvido falar no Algoritmo, mas somente na teoria. Não sabia que
havia uma implementação ativa!
Vou tentar olhar se já está no kernel 3.5 e qualquer coisa compilar e
testar.


>  Em outras palavras, sugiro que pare de se esforçar para quebrar a
>>> Internet e simplesmente deixe de considerar ICMP como exceção no
>>> controle da banda como outros já lhe sugeriram.
>>>
>>>  Não considero isso como uma quebra da internet, afinal, já fazemos
>>
>
> Se você zerar o payload de tudo quanto é ICMP, quebra sim.  Quebra o
> PMTUD na melhor das hipóteses, bem como os "destination unreachable".
>
>
>  controle de banda. Isso não é quebrar o princípio da neutralidade de
>> rede? As operadoras não zeram pacotes TOS setados na rede da gente e
>>
>
> Controle de banda agregado em si não costuma ser considerado violação de
> neutralidade.  Priorizar serviços de forma agregada por tipo (bulk,
> latência máxima (RTP, DNS), emergência) também não é costumeiramente
> considerado violação de neutralidade.  Já priorizar/despriorizar serviço
> de determinado fornecedor (Google/netflix/etc) em relação a outros, é.
> Limitar uso agregado dos enlaces de trânsito e peering por tipo de
> serviço (ex: p2p) é área cinza, e por usuário é costumeiramente
> considerado violação da neutralidade.
>
> Zerar, ou remarcar (alterar) o TOS/DSCP na borda do AS é *normal* e
> *esperado*, estando esse detalhe inclusive listado nos RFCs.  As
> marcações de QuS e significado das mesmas muda de um domínio
> administrativo para outro.  QoS e marcação de tráfego tem que ser
> acertado por acordo entre as partes, e é sim considerado ou serviço de
> valor adicionado, ou um diferencial de maior qualidade pelo mercado.
>
Não quando isso é combinado em contato com a operadora, conforme vc já
citou. Já peguei casos de quando o pacote passava de uma operadora pra
outra simplesmente sumia o ToS. Acho isso uma calamidade.


> Considero que o ideal seria que o cliente (inclusive usuário final) via
> de regra possuísse o direito de ter dois ou três prioridades de tráfego
> além do BE (best-effort), todas elas limitadas ao máximo de x% da
> largura de banda de rede contratada (o resto é ocupado pelo BE).
>
>
>  Ou, se vai insistir em interferir com os ICMPs, pelo menos use
>>> algum método menos esdrúxulo, como por exemplo, rate-limit.
>>>
>>>  Não considero um wrapper em C para simplesmente zerar o payload (e
>> não de todos os pacotes, me desculpem por não citar isso) algo
>> esdrúxulo.
>>
>
> Sinceramente, na minha opinião colocar isso em produção interferindo
> cegamente no _conteúdo_ do tráfego de terceiro (mesmo que o terceiro
> seja seu cliente) merece a classificação "esdrúxulo" sim.
>
> Até vou considerar que fazer isso de forma seletiva merece sair da
> classificação de "esdrúxulo" e passar para o apenas "incomum, e
> altamente não recomendado".  Mas você não tinha dito que era seletivo...


Desculpe, falha minha.


>
>  Fiz para aprender a usar libpcap. Bem interessante! Existem muitas
>> outras coisas que são feitas por aí que são bem mais ridículas que
>> isso.
>>
>
> Nisso, concordo totalmente!
>
>
>  Considerarei usar rate-limit no mikrotik.
>>
>
> Depois de simplesmente limitar deforma agregada, mas com menor
> prioridade de descarte que TCP e UDP, a técnica mais usada é fazer
> rate-limit mesmo.  Você pode separar isso em dois ou três grupos (se
> isso não usar recurso demais) e deixar passar pequenos bursts.
> Raramente o rate-limit vai descartar ICMP importante, que são bem menos
> comuns que o "ping" e o "pong" (echo request e echo reply).  O ruim é
> que é um rate-limit por usuário, que pode gerar problema de
> escalabilidade se for feito nas caixas de agregação.  Mas se você puder
> fazer o rate-limit na CPE, escala muito bem.


Descobri que os túneis usam echo reply e request para o tunelamento. Bastou
mudar a regra para não casar com estes pacotes e problema resolvido.
Dica do meu amigo Welisson. Obrigado Welisson.



>


> --
> Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
> IM@ - Informática de Municípios Associados
> Engenharia de Telecomunicações
> TEL +55-19-3755-6555/CEL +55-19-9293-9464
>
> Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
> e do custo que você pode evitar.
> --
> gter list    https://eng.registro.br/**mailman/listinfo/gter<https://eng.registro.br/mailman/listinfo/gter>
>