12.3. Filtros de Policiamento
Para tornar possíveis configurações mais complicadas realmente, você pode ter filtros que somente batem até certa largura de banda. Você pode declarar um filtro tanto para deixar de bater totalmente com certa taxa superior, bem como não bater somente com a largura de banda excedente a certa taxa.
Portanto, se você decidir policiar em 4mbit/s, mas 5mbit/s de tráfego estiver presente, você pode interromper a conferencia tanto do 5mbit/s completo como somente não bater 1mbit/s e enviar 4mbit/s para a classe configurada.
Se a largura de banda exceder a taxa configurada, você pode descartar um pacote, classificá-lo novamente, ou ver se um outro filtro confere com ele.
12.3.1. Formas de policiar
Existem basicamente duas formas de policiar. Se você compilou o kernel com suporte a ‘Estimators’, o kernel pode medir para cada filtro quanto de tráfego ele está passando, mais ou menos. Esses estimadores são muito fácies na CPU, porque eles simplesmente contam 25 vezes por segundo a quantidade de dados que tem passado, e calcula o bitrate a partir disso.
O outro caminho funciona novamente via um filtro Token Bucket, esse tempo vive dentro do seu filtro. O TBF somente bate com o tráfego ATÉ sua largura de banda configurada, se mais for oferecido, somente o excedente fica sujeito à ação overlimit configurada.
12.3.1.1. Com o estimador do kernel
Esse é muito simples e possui somente um parâmetro: avrate. Ou o fluxo permanece acima de avrate, e o filtro classifica o tráfego para o classid configurado, ou a sua taxa excede-o nesse caso a ação especificada é tomada, que é a ‘reclassificação’ por padrão.
O kernel usa um Exponential Weighted Moving Average (EWMA) - média de movimentação exponencial ponderada - para sua largura de banda que o torna menos sensível a rajadas curtas.
12.3.1.2. Com Filtro Token Bucket
Usa os seguintes parâmetros:
• burst/buffer/maxburst
• mtu/minburst
• mpu
• rate
Os quais se comportam normalmente idênticos a aqueles descritos na seção do Filtro Token Bucket. Favor observe contudo que se você definir o mtu de um policial TBF muito baixo, *nenhum* pacote passará, enquanto que a qdisc TBF egress justamente os passará mais lento.
Uma outra diferença é que um policial pode somente deixar um pacote, ou descartá-lo. Ele não pode retê-lo a fim de atrasá-lo.
12.3.2. Ações Overlimit
Se seu filtro decidir que ele está overlimit, ele pode tomar ‘ações’. Atualmente, quatro ações estão disponíveis:
continue
Faz esse filtro não bater, mas talvez outros filtros vão bater.
drop
Essa é uma opção muito feroz que simplesmente descarta trafego que exceder certa taxa. Ela é frequentemente usada no policial ingress e tem uso limitado. Por exemplo, você pode ter um servidor de nome que cai se for oferecido mais do que 5mbit/s de pacotes, caso no qual um filtro ingress pode ser usado para garantir que nenhum tráfego a mais seja oferecido de fato.
Pass/OK
Passa tráfego quando ok. Pode ser usado para desabilitar um filtro complicado, mas deixa-o operacional.
reclassify
Muito frequentemente recai na reclassificação de Melhor Esforço. Essa é a ação padrão.
12.3.3. Exemplos
O único exemplo real conhecido é mencionado na seção ‘Protegendo seu host de SYN floods’.
Limita o tráfego icmp entrante em 2kbit, descarta pacotes que ultrapassar o limite:
tc filter add dev $DEV parent ffff: \
protocol ip prio 20 \
u32 match ip protocol 1 0xff \
police rate 2kbit buffer 10k drop flowid :1
Limita pacotes a certo tamanho (ou seja, todos os pacotes com um tamanho maior do que 84 bytes serão descartados):
tc filter add dev $DEV parent ffff: \
protocol ip prio 20 \
u32 match tos 0 0 \
police mtu 84 drop flowid :1
Esse método pode ser usado para descartar todos os pacotes:
tc filter add dev $DEV parent ffff: \
protocol ip prio 20 \
u32 match ip protocol 1 0xff \
police mtu 1 drop flowid :1
Ele realmente descarta pacotes icmp maior do que 1 byte. Enquanto que pacotes com um tamanho de 1 byte são possíveis na teoria, você não os encontraria em uma rede real.
Autores Originais dos textos:
Bert Hubert (Netherlabs BV)
bert.hubert@netherlabs.nl
Thomas Graf (Autor de Seção)
tgraf@suug.ch
Gregory Maxwell (Autor de Seção)
greg@linuxpower.cx
Remco van Mook (Autor de Seção)
remco@virtu.nl
Martijn van Oosterhout (Autor de Seção)
kleptog@cupid.suninternet.com
Paul B Schroeder (Autor de Seção)
paulsch@us.ibm.com
Jasper Spaans (Autor de Seção)
jasper@spaans.ds9a.nl
Pedro Larroy (Autor de Seção)
piotr@member.fsf.org
Bert Hubert (Netherlabs BV)
bert.hubert@netherlabs.nl
Thomas Graf (Autor de Seção)
tgraf@suug.ch
Gregory Maxwell (Autor de Seção)
greg@linuxpower.cx
Remco van Mook (Autor de Seção)
remco@virtu.nl
Martijn van Oosterhout (Autor de Seção)
kleptog@cupid.suninternet.com
Paul B Schroeder (Autor de Seção)
paulsch@us.ibm.com
Jasper Spaans (Autor de Seção)
jasper@spaans.ds9a.nl
Pedro Larroy (Autor de Seção)
piotr@member.fsf.org
Nenhum comentário:
Postar um comentário