Boa tarde.
Desculpem reabrir este tópico, mais alguém tem alguma novidade neste
assunto?
Hoje perdi algumas horas novamente tentando atualizar o FreeBSD 9 para o
10-RELEASE e caí no mesmo problema, tanto que nem lembrava mais disso e ai
cai aqui nesta thread aberta por mim mesmo com o mesmo problema.
Enfim, agora estou migrando de NATD para in-Kernel NAT, mais o problema do
controle de MAC para Pipes configurados como Upload está o mesmo.
Será que o pessoal do desenvolvimento ficou a par deste bug?
--
Att.
__
Márcio Elias Hahn do Nascimento
Bacharel em Tecnologias da Informação e Comunicação - TIC
Cel: (55) 48-8469-1819
Emails: marcioel...@bsd.com.br / marcioel...@gmail.com
Skype: marcioeliash...@hotmail.com
FreeBSD - The Power To Serve
2014-02-14 9:47 GMT-02:00 Márcio Elias marcioel...@gmail.com:
2014-02-14 2:08 GMT-02:00 Marcelo Gondim gon...@bsdinfo.com.br:
Em 14/02/14 00:09, Márcio Elias escreveu:
2014-02-13 15:24 GMT-02:00 Marcelo Gondim gon...@bsdinfo.com.br:
Em 13/02/14 11:31, Márcio Elias escreveu:
2014-02-12 23:59 GMT-02:00 Márcio Elias marcioel...@gmail.com:
2014-02-12 23:42 GMT-02:00 Renato Frederick ren...@frederick.eti.br
:
Em 12/02/14 23:31, Márcio Elias escreveu:
Se funcionar, antes de relatar como BUG ainda vou fazer mais um
teste,
excluindo e recriando a máquina virtual da versão 10, pra realmente
descartar qualquer possibilidade de erro de configuração.
Se puder virtualizar em vmware e mandar o feedback prá nós, fico
agradecido!
-
Não tenho VMWare aqui fera, soh que eu instale a versão Desktop na
minha
máquina e faça os testes, o difícil vai ser tempo pra isso.
Se alguém tiver um ambiente que possa testar, mando o conjunto de
configurações/regras mínimas que estou usando pra ver se funciona.
Infelizmente tenho os resultados dos testes realizados em uma máquina
real
com FreeBSD 10-release.
O resultado foi o mesmo da máquina virtualizada, não sei por que mais
ao
jogar o tráfego de upload para o pipe, o cliente não navega mais...
*00100 2786 1389706 divert 8668 ip from any to me in recv re0*
*00200 1796 444771 divert 8668 ip from 192.168.0.0/16
http://192.168.0.0/16 to any out xmit re0*
*00300 1621 1013920 pipe 150 ip from any to 192.168.5.18
MAC XX:XX:XX:XX:XX:XX any*
*--- 00400 534 74471 pipe 155 ip from 192.168.5.18 to any
##aqui
tinha controle de MAC, mais testei sem e mesmo assim não foi*
*65535 19188 6448077 allow ip from any to any*
Não acredito que seja um BUG, deve ter mudado alguma coisa com o
FreeBSD
10, alguém ai tem a oportunidade de reproduzir esse teste?
Marcio fiz um teste aqui e deu o mesmo erro também. Mandei até um
e-mail
pros caras explicando. Aí fui fazer o mesmo teste entrando com as
regras
manualmente e acho que descobri o problema.
Quando rodo as regras através do script não aparece o erro que dá na
hora do pipe. Minhas regras de teste:
ipfw add pipe 1 ip from 67.xxx.89.78 to any 80 out via xn0
ipfw add pipe 2 ip from any 80 to 67.xxx.89.78 in via xn0
ipfw pipe 1 config bw 1024Kbit/s queue 128 burst 2M
ipfw pipe 2 config bw 1024Kbit/s queue 128 burst 2M
Rodando as 2 do pipe manualmente deu a mensagem abaixo que a queue size
tinha que ser maior igual à 2 e menor igual à 100. Refiz a regra usando
queue com 100 e funcionou normalmente. Existe uma sysctl que permite
aumentar o valor da queue: net.inet.ip.dummynet.pipe_slot_limit onde
posso aumentar para 128 e aí minhas regras também funcionariam. Por um
acaso não é isso que está acontecendo contigo?
# ipfw pipe 1 config bw 1024Kbit/s queue 128 burst 2M
ipfw: 2 = queue size = 100
# ipfw pipe 2 config bw 1024Kbit/s queue 128 burst 2M
ipfw: 2 = queue size = 100
[]'s
Gondim
-
Humm, mais eu não estou configurando o pipe desta forma, estou
especificando somente a largura de banda, veja como estou fazendo:
ipfw pipe 1 config bw 10Mbits#exemplo para um pipe de 10M
Outra coisa é que para o meu caso não especifico portas, todo o tráfego
passa por esse pipe, isso é o que uso para limitar a velocidade
contratada
pelos clientes, por isso tenho um pipe de up e um de down pra cada
cliente.
Será que é o mesmo caso?
Eu coloquei a porta específica apenas para fazer um teste, porque senão
poderia travar meu acesso remoto naquela VM, aí para não correr o risco,
fiz somente com a porta 80. :)
Pro controle ficar legal é bom setar a queue que seria a velocidade / 8
que no seu caso daria uma queue de 1280 mas aí você precisa setar o
net.inet.ip.dummynet.pipe_slot_limit para 1280.
Quando você seta o seu pipe... o que aparece quando você faz: ipfw pipe
show ?
No meu caso deu o problema porque os pipes não carregavam, não apareciam
no comando acima.
[]'s
Gondim
Fica assim por exemplo:
[root@teste /home/sulonline]# ipfw
