+ Responder ao Tópico



  1. #1

    Padrão Star-OS e Cbq

    Pro pessoal que ta utilizando o Star-OS.

    Troquei todos os minhas aps 2000 por star-os, e estou realmente espantado pelo desempenho e funcionalidades deste sistema.

    Queria trocar informacoes com quem ja usa o Star-OS a mais tempo, eu estou querendo otimizar o maximo o troughtput do meu baseado em clientes simultaneos. O maximo que consegui foi 80 clientes simultaneos sem problemas de lentidao, isso fazendo controle Layer7 em peer-to-peer com cbq e eliminando porqueiras como netbios e tb controlando alguns servicos por limite de conexoes CONNLIMIT.

    Estava querendo fazer controle de banda dos clientes, mas de uma forma generica, pois ja tenho um controle no meu servidor.

    Tipo dar no maximo 350kbps de DOWNP e 128 kbps de UP para cada cliente na interface do card em poucas linhas no cbq. Eu ate tentei fazer uma regra, mas nao tive sucesso, a regra na verdade limitou toda a rede a 350 down e 128 up, fazendo apenas o compartilhamento destes valores entre os clientes.

    Se alguem puder ajudar, ficarei muy grato.

  2. #2

    Padrão Star-OS e Cbq

    Pelo que entendi, vc gostaria de colocar uma regra de limitação de banda no Star-OS para cada cliente, eh isso??? Se for, segue na regra que eu uso no script do CBQ no próprio Star-OS:

    qshape NomedoCliente 130 bw 350k 180k 10.0.0.10 on wlan1

    Onde:

    NomedoCliente = um nome qualquer para identificar o cliente
    130 = número que identifica a classe. Se vc quer uma regra para cada cliente, use um número de identificação da classe para cada cliente
    350k = banda de Download para o cliente
    180k = banda de Upload para o Cliente
    10.0.0.10 = IP do cliente
    wlan1 = nome da interface wireless onde o cliente se conecta no rádio

    Espero ter ajudado...

  3. #3

    Padrão Star-OS e Cbq

    Citação Postado originalmente por _AGM_
    Pelo que entendi, vc gostaria de colocar uma regra de limitação de banda no Star-OS para cada cliente, eh isso??? Se for, segue na regra que eu uso no script do CBQ no próprio Star-OS:

    qshape NomedoCliente 130 bw 350k 180k 10.0.0.10 on wlan1

    Onde:

    NomedoCliente = um nome qualquer para identificar o cliente
    130 = número que identifica a classe. Se vc quer uma regra para cada cliente, use um número de identificação da classe para cada cliente
    350k = banda de Download para o cliente
    180k = banda de Upload para o Cliente
    10.0.0.10 = IP do cliente
    wlan1 = nome da interface wireless onde o cliente se conecta no rádio

    Espero ter ajudado...
    Nao e bem assim, eu nao queria criar regra por regra para cada cliente. Queria utilizar uma regra generica para todos os clientes, pois todos terao um padrao de acesso.

  4. #4

    Padrão Star-OS e Cbq

    Bom, dessa forma eu desconheço se existe a possibilidade de fazer. Se você especificar uma range de IP´s (digamos que seus clientes estejam dentro de uma mesma range: 10.0.0.1 a 10.0.0.254), obviamente a banda informada será dividida para todas as máquinas que estão nessa range...

  5. #5

    Padrão Star-OS e Cbq

    Citação Postado originalmente por _AGM_
    Bom, dessa forma eu desconheço se existe a possibilidade de fazer. Se você especificar uma range de IP´s (digamos que seus clientes estejam dentro de uma mesma range: 10.0.0.1 a 10.0.0.254), obviamente a banda informada será dividida para todas as máquinas que estão nessa range...
    Ai AGM blz!

    Aki, eu ate criei uma regra no Star-OS dessa forma:

    bi-pipe 1000 bw 2048k 2048k
    qshape 20:253 bw 350k 100k parent 1000 10.0.1.20 on $client


    Vou te explicar o porque desta regra, pra vc me dizer se terei a eficiencia que quero chegar.

    Pelo que sei um cartao orinoco tem no maximo 2mbps de troughput, acima disso o desempenho cai pelo alto trafego. Como meu link e de 2mbps, achei interessante colocar o trafego maximo em 2mbps, e nos cards, uma velocidade generica (para todos os usuarios) a 350k de Download (que e limite maximo do maior plano que tenho) e 100k de upload (que tb e o limite maximo de up do maior plano).

    Neste caso estou usando um range do ips: 10.0.1.20 a 10.0.1.253, para definir esta velocidade.

    Agora te pergunto, estou usando esta regra corretamente... e tipo o limite total do parent, a 2048, poderia ser aumentado, tipo o cartao poderia ate aguentar mais.

    obs: eu tambem faco controle de banda no meu firewall atras deste Star-os com velocidades mais baixas: 350-100, 200-80, 100-50

    Eu sou meio novato nesse assunto de Star-OS, e vi que vc tem uns posts na star-os internacional, e poderia me ajudar ou ate trocar experiencias.

    Grato.

    E desculpe pela falta dos acentos, estou com as teclas de acento do laptop quebradas... hhehehhe... falow amigo

  6. #6

    Padrão Star-OS e Cbq

    Bem, pelo que entendi, os seus clientes estão na range que vai do IP 10.0.1.20 ao IP 10.0.1.253, certo??? Também suponho que vc tenha apenas 1 cartão nesse AP, certo? Partindo desse princípio, vc está criando um PIPE de 2 megas de download e 2 megas de upload... Todos os clientes irão compartilhar desses 2 megas de down e up (PARENT) e terão como velocidade máxima cada um 350k de down e 100k de up... Mas eu acho que vc esqueceu de colocar um nome para essa regra logo após o comando "qshape"... Olha o exemplo no próprio script do CBQ do Star-OS:

    ########### (simple qshape sample with ip range)
    # Shape client IPs between 192.168.10.1 and 192.168.10.9 to 128k #download, and 56k upload, each using their own queue.
    #qshape joe-user-list 101:109 bw 128k 56k 192.168.10.1 on $client

    Isso quer dizer que sua regra está correta, apenas falta colocar um nome, que nesse exemplo é "joe-user-list"... Ainda não testei isso, mas deve funcionar... Se não funcionar dessa forma, você pode usar o outro exemplo que o script dá:

    bi-pipe 1000 bw 2048k 2048k
    qshape IP20 20 bw 350k 100k parent 1000 10.0.1.20 on $client
    qshape IP21 21 bw 350k 100k parent 1000 10.0.1.21 on $client
    qshape IP22 22 bw 350k 100k parent 1000 10.0.1.22 on $client

    e assim por diante, até o final da range....

    Veja bem, naum testei nada disso, mas os exemplos do script estão assim... Com uma dessas duas formas vc vai conseguir dividir 2 megas de banda para todos os clientes da sua range, limitando para 350k de down e 100k de up para cada um...


    Testa aeh e poste os resultados...

  7. #7

    Padrão Star-OS e Cbq

    Apenas mais um comentário que me dei conta depois de ter postado a mensagem anterior: acho que ele não deve aceitar os parâmetros de range de IP´s (20:253) e o PARENT ao mesmo, tempo, senão ele teria demonstrado tudo num exemplo soh, pois quando ele usa o PARENT no exemplo, ele não especifica range de IP´s, mas sim uma regra qshape para cada IP...

  8. #8

    Padrão Star-OS e Cbq

    Citação Postado originalmente por _AGM_
    Apenas mais um comentário que me dei conta depois de ter postado a mensagem anterior: acho que ele não deve aceitar os parâmetros de range de IP´s (20:253) e o PARENT ao mesmo, tempo, senão ele teria demonstrado tudo num exemplo soh, pois quando ele usa o PARENT no exemplo, ele não especifica range de IP´s, mas sim uma regra qshape para cada IP...
    AGM funcionou, mas sem especificar o nome do shape. E a rede wireless virou outra coisa, show de bola....

    Report do CBQ


    file wireless interfaces routing advanced hotspot services system
    ┌─[·]──────────────────────────────────────────────────────────────────── CBQ / QoS Report Viewer ─────────────────────────────────────────────────────────────────────[|]─┐
    bi-pipe 20 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.20 on wpcm0 ^│
    │bi-pipe 21 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.21 on wpcm0 ·│
    │bi-pipe 22 ( 42.77K / 12.21K): rx: 8.03M, 0.00B/sec tx: 1.80M, 0.00B/sec, src 10.0.1.22 on wpcm0 ▒│
    │bi-pipe 23 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.23 on wpcm0 ▒│
    │bi-pipe 24 ( 42.77K / 12.21K): rx: 7.69M, 0.00B/sec tx: 2.35M, 0.00B/sec, src 10.0.1.24 on wpcm0 ▒│
    │bi-pipe 25 ( 42.77K / 12.21K): rx: 6.16M, 3.12K/sec tx: 788.32K, 2.23K/sec, src 10.0.1.25 on wpcm0 ▒│
    │bi-pipe 26 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.26 on wpcm0 ▒│
    │bi-pipe 27 ( 42.77K / 12.21K): rx: 27.85K, 0.00B/sec tx: 48.65K, 0.00B/sec, src 10.0.1.27 on wpcm0 ▒│
    │bi-pipe 28 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.28 on wpcm0 ▒│
    │bi-pipe 29 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.29 on wpcm0 ▒│
    │bi-pipe 30 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.30 on wpcm0 ▒│
    │bi-pipe 31 ( 42.77K / 12.21K): rx: 78.48M, 10.00K/sec tx: 7.41M, 1.04K/sec, src 10.0.1.31 on wpcm0 ▒│
    │bi-pipe 32 ( 42.77K / 12.21K): rx: 6.68M, 0.00B/sec tx: 1.91M, 0.00B/sec, src 10.0.1.32 on wpcm0 ▒│
    │bi-pipe 33 ( 42.77K / 12.21K): rx: 15.07M, 0.00B/sec tx: 562.52K, 0.00B/sec, src 10.0.1.33 on wpcm0 ▒│
    │bi-pipe 34 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.34 on wpcm0 ▒│
    │bi-pipe 35 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.35 on wpcm0 ▒│
    │bi-pipe 36 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.36 on wpcm0 ▒│
    │bi-pipe 37 ( 42.77K / 12.21K): rx: 23.57M, 0.00B/sec tx: 3.53M, 0.00B/sec, src 10.0.1.37 on wpcm0 ▒│
    │bi-pipe 38 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.38 on wpcm0 ▒│
    │bi-pipe 39 ( 42.77K / 12.21K): rx: 16.44M, 3.10K/sec tx: 15.94M, 2.99K/sec, src 10.0.1.39 on wpcm0 ▒│
    │bi-pipe 40 ( 42.77K / 12.21K): rx: 19.79M, 0.00B/sec tx: 8.22M, 0.00B/sec, src 10.0.1.40 on wpcm0 ▒│
    │bi-pipe 41 ( 42.77K / 12.21K): rx: 63.83M, 0.00B/sec tx: 6.06M, 0.00B/sec, src 10.0.1.41 on wpcm0 ▒│
    │bi-pipe 42 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.42 on wpcm0 ▒│
    │bi-pipe 43 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.43 on wpcm0 ▒│
    │bi-pipe 44 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.44 on wpcm0 ▒│
    │bi-pipe 45 ( 42.77K / 12.21K): rx: 15.66M, 0.00B/sec tx: 5.55M, 0.00B/sec, src 10.0.1.45 on wpcm0 ▒│
    │bi-pipe 46 ( 42.77K / 12.21K): rx: 35.78M, 100.25B/sec tx: 13.26M, 145.75B/sec, src 10.0.1.46 on wpcm0 ▒│
    │bi-pipe 47 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.47 on wpcm0 ▒│
    │bi-pipe 48 ( 42.77K / 12.21K): rx: 17.96M, 0.00B/sec tx: 13.83M, 0.00B/sec, src 10.0.1.48 on wpcm0 ▒│
    │bi-pipe 49 ( 42.77K / 12.21K): rx: 23.62M, 2.84K/sec tx: 29.26M, 116.25B/sec, src 10.0.1.49 on wpcm0 ▒│
    │bi-pipe 50 ( 42.77K / 12.21K): rx: 48.31M, 0.00B/sec tx: 2.60M, 0.00B/sec, src 10.0.1.50 on wpcm0 ▒│
    │bi-pipe 51 ( 42.77K / 12.21K): rx: 49.70M, 4.49K/sec tx: 2.87M, 136.00B/sec, src 10.0.1.51 on wpcm0 ▒│
    │bi-pipe 52 ( 42.77K / 12.21K): rx: 2.14M, 0.00B/sec tx: 329.71K, 0.00B/sec, src 10.0.1.52 on wpcm0 ▒│
    │bi-pipe 53 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.53 on wpcm0 ▒│
    │bi-pipe 54 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.54 on wpcm0 ▒│
    │bi-pipe 55 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.55 on wpcm0 ▒│
    │bi-pipe 56 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.56 on wpcm0 ▒│
    │bi-pipe 57 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.57 on wpcm0 ▒│
    │bi-pipe 58 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.58 on wpcm0 ▒│
    │bi-pipe 59 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.59 on wpcm0 ▒│
    │bi-pipe 60 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.60 on wpcm0 ▒│
    │bi-pipe 61 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.61 on wpcm0 ▒│
    │bi-pipe 62 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.62 on wpcm0 ▒│
    │bi-pipe 63 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.63 on wpcm0 ▒│
    │bi-pipe 64 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.64 on wpcm0 ▒│
    │bi-pipe 65 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.65 on wpcm0 ▒│
    │bi-pipe 66 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.66 on wpcm0 ▒│
    │bi-pipe 67 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.67 on wpcm0 ▒│
    │bi-pipe 68 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.68 on wpcm0 ▒│
    │bi-pipe 69 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.69 on wpcm0 ▒│
    │bi-pipe 70 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.70 on wpcm0 ▒│
    │bi-pipe 71 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.71 on wpcm0 ▒│
    │bi-pipe 72 ( 42.77K / 12.21K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 10.0.1.72 on wpcm0 CPU Load: 16.8% | SERVER Edition v2.10.0 (build 4693)

  9. #9

    Padrão Star-OS e Cbq

    Só me diz como ficou esse controle de banda: cada cliente usufrui de 2 megas de banda, chegando no máximo a 350 kbps, é isso??? Ou seja, se tiver banda livre desses dois megas, cadausuário pode usar 350 kbps???

  10. #10

    Padrão Star-OS e Cbq

    Citação Postado originalmente por _AGM_
    Só me diz como ficou esse controle de banda: cada cliente usufrui de 2 megas de banda, chegando no máximo a 350 kbps, é isso??? Ou seja, se tiver banda livre desses dois megas, cadausuário pode usar 350 kbps???
    Olha o valor de 2Mbps eu coloquei pq, e o valor maximo que quero que o cartao chegue, pois acima disso o troughtput detona com a rede. Agora e isso mesm: compartilho os 2 Mbps por cartao, sendo que o usuario podera ter no maximo 350 kbps de Down e 100 de UP, mesmo com banda sobrando. Agora um detalhe... e a velocidade maxima por clientes ate o AP... pois a maioria dos clientes quando chega no meu gateway tb sao limitados a velocidades mais baixas: tipo 100-50, 200-80...