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 é: [EMAIL PROTECTED], que passarei para a parte administrativa. Grato On Dec 7, 2007 1:26 PM, jaitony gmail <[EMAIL PROTECTED]> wrote: > Sequizer nos locamos para vc > > entre em contato > > > Renato de Oliveira Diogo escreveu: > > > On Dec 7, 2007 10:26 AM, Renato Frederick <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >>>>> > >>>>> [EMAIL PROTECTED] > >>>>> [EMAIL PROTECTED] > >>>>> > >>>>> ------------------------- > >>>>> 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 > >>> > >>> [EMAIL PROTECTED] > >>> [EMAIL PROTECTED] > >>> ------------------------- > >>> 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 [EMAIL PROTECTED] [EMAIL PROTECTED] ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
