> 
> 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 :)

> 
> 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!

>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

> 
> []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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Reply via email to