[FUG-BR] [RESOLVIDO] Re: RES: RES: Controle de banda de sub-blocos dentro de um bloco grande
Renato de Oliveira Diogo
renato.diogo em gmail.com
Sábado Dezembro 8 19:43:18 BRST 2007
Grato a todos por me ajudar esclarecer minhas dúvidas
Olá jaitonys
até este momento ainda não teríamos a necessidade disso, mas caso
queira passar seus contatos para conversarmos, podemos ver com o que
vc exatamente trabalha e caso haja algum interesse. Meu e-mail é:
renato.diogo em gmail.com, que passarei para a parte administrativa.
Grato
On Dec 7, 2007 1:26 PM, jaitony gmail <jaitonys em gmail.com> wrote:
> Sequizer nos locamos para vc
>
> entre em contato
>
>
> Renato de Oliveira Diogo escreveu:
>
> > On Dec 7, 2007 10:26 AM, Renato Frederick <frederick em dahype.org> wrote:
> >
> >>> Interessante saber q não precisarei fazer a divisão dos blocos antes
> >>> do bridge para o controle. Vai me poupar uma sobrecarga de controle. E
> >>> ainda não tinha me atentado da questão de passar dois blocos
> >>> diferentes para o mesmo cliente na mesma faixa de banda, foi um
> >>> exemplo seu que já me atentou neste detalhe q eu tinha deixado passar.
> >>> Vlw.
> >>>
> >> Por isto você usa bridge ao invés de subnet :)
> >>
> >
> > Muito bom, agori fixo esse conceito.
> >
> >
> >>> Vou verificar a questão de bloqueios dos blocos quando não utilizados.
> >>> Mas normalmente os blocos não utilizados não estão roteados (salvo
> >>> raríssimas excessões).
> >>>
> >>> Realmente entre os clientes não entraria neste controle. De inicio
> >>> isto não seria um problema (poderia ser até uma vantagem), porém num
> >>> futuro o meu meio pode saturar acarretando problemas nisto. Mas esses
> >>> roteadores tem um controle de banda dele, o ruim deste controle de
> >>> banda é que eu não posso estipular UP e DOWN separadamente, por
> >>> exemplo 1024K de UP e 1024K de DOWN, a única coisa que eu posso
> >>> especificar é que o meio é controlado por 2048K total (soma do UP e
> >>> DOWN).
> >>>
> >> É cisco? Com rate limit você pode limitar input e output das interfaces:
> >>
> >> http://www.cisco.com/en/US/docs/ios/12_2/qos/command/reference/qrfcmd8.html
> >>
> >> só observe o consumo de CPU!
> >>
> >>
> >
> > Não são CISCOs, a minha própria estrutura wireless tem seu roteamento,
> > e estamos utilizando ela para este roteamento. Aumentando a carga aí
> > sim avaliamos em colocar um dispositivo somente para isto, mas ainda
> > seria um investimento desnecessário e impossível no momento.
> > (Já respondendo o email do jaitony :) )
> >
> >
> >>> Mas para amenizar isso, faço o controle de UP separado de DOWN
> >>> no bridge para o link com a telecom (o que nosso gargalo hoje) e faço
> >>> o controle da soma do UP e DOWN contratado no router na ponta do
> >>> cliente. Caso contrario eu teria que colocar um bridge em cada cliente
> >>> e ficaria muitas máquinas a ser gerenciada.
> >>>
> >> Isto seria impraticável...
> >>
> >>
> >>> O meio de enlace meu entre os roteadores é wireless, creio que é por
> >>> isso o problema de controle de banda nos routers.
> >>>
> >> Com certeza, rádios wireless não irão informar às interfaces do roteadores
> >> conectados à nuvem quando o meio está congestionado ou priorizar tráfego,
> >> você terá que fazer isto "na mão" :)
> >>
> >>
> >>> O controle de MAC na verdade não seria para estes clientes, com
> >>> certeza o cliente é o responsável pela sua rede. Na verdade esse
> >>> controle de MAC será uma funcionalidade que estaria agregando na mesma
> >>> estrutura para fazer um controle de clientes de acesso (que são
> >>> clientes residenciais, algumas empresas que não necessitam/querem um
> >>> acesso mais garantido), e estes entraria em uma banda compartilhada,
> >>> com ou sem IPs dinâmicos, essas coisas. Mas esta estrutura seria uma
> >>> outra máquina, como exemplo na posição do "Router cliente acesso".
> >>>
> >> Você pode colocar um freebsd como AP em um PC montado na torre ou usar uma
> >> mini distribuição(tinybsd) em placas próprias(wrap).
> >> Tem soluções vendidas em caixas no mercado também como
> >> staros/mikrotik/routeros... houve uma discussão sobre isto aqui a alguns
> >> dias
> >>
> >>
> >>
> >
> > A sim, esta é a ideia. Hoje já trabalhamos com uma estrutura, porém
> > estamos vendo a possibilidade de procurar alternativas dentre as que
> > resolvem alguns problemas que estamos tendo, ou substituição ou a
> > criação de uma nossa própria.
> >
> > []s
> >
> >
> >>> []s
> >>>
> >>> On Dec 7, 2007 7:27 AM, Renato Frederick <frederick em dahype.org> wrote:
> >>>
> >>>> Você pode colocar a bridge neste ponto (*) sem problema algum, não
> >>>>
> >>> precisa
> >>>
> >>>> dividir blocos, afinal a bridge está aí exatamente para não precisar
> >>>>
> >>> de
> >>>
> >>>> subrede.
> >>>>
> >>>> Talvez seja interessante ativar algum tipo de filtro para que blocos
> >>>>
> >>> IP não
> >>>
> >>>> utilizados não sejam roteados, é uma proteção a mais, mas dependendo
> >>>>
> >>> do
> >>>
> >>>> tamanho da sua rede isto pode se tornar inviável.
> >>>>
> >>>> Daí na bridge coloque o DUMMYNET criando um pipe limitando a /29 com
> >>>>
> >>> a
> >>>
> >>>> velocidade total contratada. Se o cliente adquirir mais blocos altere
> >>>>
> >>> a
> >>>
> >>>> máscara ou faça um {bloco_1/24 or bloco2/28} para agregar as regras,
> >>>>
> >>> bem
> >>>
> >>>> simples.
> >>>>
> >>>> Só que neste cenário o controle de banda só irá ocorrer para a
> >>>>
> >>> Internet
> >>>
> >>>> afora, se o cliente1 acessar o cliente5, como a bridge está em outro
> >>>> segmento, eles usarão toda a banda disponível de um até o outro.
> >>>>
> >>>> Como você está ligando o router1 até o cliente1 e cliente2? Como é o
> >>>> protocolo de enlace? Voce tem algum tipo de switch frame relay/mpls
> >>>>
> >>> aí no
> >>>
> >>>> meio? O ideal é que o controle de banda seja feito no local loop para
> >>>>
> >>> evitar
> >>>
> >>>> saturação do seu backbone.
> >>>>
> >>>> Como você está colocando roteadores nas pontas, não há porque
> >>>>
> >>> controlar Mac,
> >>>
> >>>> voce tem que se preocupar apenas com o IP, o que o cliente faz atrás
> >>>>
> >>> do
> >>>
> >>>> roteador não lhe atrapalha, até porque mesmo que alguém ative uma
> >>>>
> >>> classe que
> >>>
> >>>> não esteja em uso, ela não vai passar do router1/2/3, etc.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Bom, entendi seu esquema, mas estou tentando tratar algumas coisas
> >>>>> antes de chegar na rede final onde fica o cliente.
> >>>>>
> >>>>> Vou tentar montar +/- como está minha rede:
> >>>>>
> >>>>> ===============================================================
> >>>>> Router com telecom
> >>>>> |
> >>>>> |*
> >>>>> |
> >>>>> |--Router 1
> >>>>> | | - Router cliente 1
> >>>>> | |
> >>>>> | | - Router cliente 2
> >>>>> | |
> >>>>> | | - Router 1.1
> >>>>> | | - Router cliente 5
> >>>>> | |
> >>>>> | | - Router clientes acesso
> >>>>> |
> >>>>> | - Bridge 1
> >>>>> |
> >>>>> | | - clientes de acesso
> >>>>> |
> >>>>> |
> >>>>> |
> >>>>> | - Bridge 2
> >>>>> |
> >>>>> | | - clientes de acesso
> >>>>> |
> >>>>> | .....
> >>>>> |
> >>>>> | - Bridge N
> >>>>> |
> >>>>> | - clientes de acesso
> >>>>> |
> >>>>> |--Router 2
> >>>>> | | - Router cliente 3
> >>>>> |
> >>>>> |--Router 3
> >>>>> | | - Router cliente 4
> >>>>> |
> >>>>> |...
> >>>>> |--Router N
> >>>>> | |- Router cliente N
> >>>>>
> >>>>>
> >>>>>
> >>> =====================================================================
> >>>
> >>>>> Bom, seguindo o desenho acima, o "Router com telecom" vai repassar
> >>>>>
> >>> os
> >>>
> >>>>> blocos de acordo com as necessidades de cada segmento de rede meu.
> >>>>> Exemplo: o cliente 4 precisa de um bloco /25, então o "Router com
> >>>>> telecom" passará esse bloco para o Roteador 4. O cliente 3 precisa
> >>>>>
> >>> de
> >>>
> >>>>> um bloco /29, então o "Router com telecom" passará esse bloco para
> >>>>>
> >>> o
> >>>
> >>>>> Roteador 3.
> >>>>> Agora no caso do cliente 1 e 2, recebe um bloco de acordo com as
> >>>>> necessidades/contrato, e pode haver expansão de mais clientes.
> >>>>>
> >>> Então
> >>>
> >>>>> designei um bloco /24 do "Router com telecom" para o Roteador 1, e
> >>>>>
> >>> o
> >>>
> >>>>> roteador 1 faz a divisão do bloco /24, dando um /29 para o cliente
> >>>>>
> >>> 1 e
> >>>
> >>>>> /28 para o cliente 2, assim por diante.
> >>>>>
> >>>>> A maioria destes roteadores não tem algumas das funções que
> >>>>>
> >>> preciso,
> >>>
> >>>>> como controle de banda (efetivo), controle de MAC, em alguns dos
> >>>>> casos... Então eu precisaria, de inicio um controle de banda mais
> >>>>> efetivo, controlando 1024K para o cliente 4, 2048K para o cliente
> >>>>>
> >>> 1,
> >>>
> >>>>> 6144K para o cliente 3, assim por diante... 10240K para o "Router
> >>>>> cliente acesso" (este sim faz a redivisão de banda para os clientes
> >>>>>
> >>> de
> >>>
> >>>>> acesso). Observe, mesmo eu ter citado o contole de MAC, a minha
> >>>>> preocupação no momento é o controle de banda para blocos de rede.
> >>>>>
> >>>>> Então pensei em colocar um bridge (marcado com *) para controle de
> >>>>> banda entre o "Router com telecom" e os Router N.
> >>>>>
> >>>>> Então aí fica a questão no roteamento de um bloco /24 para um
> >>>>>
> >>> roteador
> >>>
> >>>>> de nivel mais baixo (Router 1) e este fazer a divisão (/29,
> >>>>>
> >>> /28...),
> >>>
> >>>>> sendo que o controle de banda é antes deste ponto na estrutura. Ou
> >>>>> seja, para um controle total e efetivo, é necessário o bloco já
> >>>>>
> >>> estar
> >>>
> >>>>> divido exatamente, ou posso tratar o controle de banda para um
> >>>>>
> >>> bloco
> >>>
> >>>>> /29 (cliente 1) no bridge que está num segmento que o bloco roteado
> >>>>> ainda é /24.
> >>>>>
> >>>>> Caso isto não seja possivel, terei que fazer a divisão de blocos no
> >>>>> "Router com telecom" e gerar muitas entradas de roteamentos nos
> >>>>> Routers...
> >>>>>
> >>>>> []s
> >>>>>
> >>>>> --
> >>>>> ________________________________________________
> >>>>> Renato de Oliveira Diogo
> >>>>>
> >>>>> Bacharel em Ciência da Computação
> >>>>> UNESP - Bauru
> >>>>>
> >>>>> renato.diogo em gmail.com
> >>>>> renato.diogo em yahoo.com.br
> >>>>>
> >>>>> -------------------------
> >>>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
> >>>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >>>>>
> >>>> -------------------------
> >>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
> >>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >>>>
> >>>>
> >>>
> >>> --
> >>> ________________________________________________
> >>> Renato de Oliveira Diogo
> >>>
> >>> Bacharel em Ciência da Computação
> >>> UNESP - Bauru
> >>>
> >>> renato.diogo em gmail.com
> >>> renato.diogo em yahoo.com.br
> >>> -------------------------
> >>> Histórico: http://www.fug.com.br/historico/html/freebsd/
> >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >>>
> >> -------------------------
> >> Histórico: http://www.fug.com.br/historico/html/freebsd/
> >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >>
> >>
> >>
> >
> >
> >
> >
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
--
________________________________________________
Renato de Oliveira Diogo
Bacharel em Ciência da Computação
UNESP - Bauru
renato.diogo em gmail.com
renato.diogo em yahoo.com.br
Mais detalhes sobre a lista de discussão freebsd