[GTER] IPs válidos "desperdiçados"

[Eduardo Rigler]

Na discagem sob demanda se o CPE do cliente continuar "online" o IP não
seria liberado. E se entendi bem, caso o NTP (exemplo) do próprio CPE ou de
outro device simples atrás dele estiver ativado já é suficiente para a
conexão não ser derrubada, certo?

Todos tempos vários exemplos de devices inofensivos que mesmo em stand-by
ficam o tempo todo enviando/recebendo "pings" de/para a internet o tempo
todo, seja celulares/tablets com notificações push, smartvs com ntp,
videogames contatando as nuvens dos fabricantes buscando atualizações de
firmware/jogos, e por aí vai.....

Acho que essa conta de 20% não está considerando todas as variáveis
possíveis, a menos seus clientes WiFi utilizem apenas a placa PCI num
desktop "de mesa" e de alguma forma vc consiga bloquear o compartilhamento
interno da conexão na casa do cara isso ainda vai te consumir bastante
fosfato :-)


[]'s

Em 4 de maio de 2015 11:02, Osvaldo T Crispim Filho <osvaldotcf at gmail.com>
escreveu:

> Blz, pessoal, valeu as experiências.
>
> Minha ideia é um script bash nos rádios (meu caso), firewall para bloquear
> bogons isto limita a saída somente para Internet, monitoramento da contagem
> de tráfego na WAN, a partir de um certo valor o release do Ip Válido.
>
> Daí vem o problema dos serviços tipo câmera, entre outros, aqui, geralmente
> o pessoal paga para ter IPs válidos fixos para estes serviços e isto é uma
> opção dos instaladores de câmeras, não nossa. Estou indo mais além e
> pensando na desconexão total do rádio desligando a WLAN até o mesmo
> "precisar" de internet, tudo são possibilidades e testes, as vezes não
> conseguimos nada com o destino mas ganhamos muito com o caminho!
>
> O cenário que estou trabalhando é aquele em que o cliente sai para
> trabalhar e fica conectado sem ninguém utilizar a conexão. Estamos
> levantando este número e ele tá girando em torno de 20%, é o pessoal que
> somente acessa à noite e um pouco logo cedo.
>
> Estou levando em consideração um grupo específico de usuários, sei que tem
> muito a ser ponderado e por isso mesmo pedi a opinião de vocês.
>
> Este é um caminho que estou analisando e que talvez percorra, muito
> obrigado pelas opiniões.
>
>
> Em 4 de maio de 2015 09:33, Douglas Fischer <fischerdouglas at gmail.com>
> escreveu:
>
> > A expressão "tosar porco" me vem à cabeça.
> > É muito grito para pouca lã.
> >
> > Me pergunto qual o ganho efetivo dessas práticas.
> > Faz-se tudo isso, e aí o cabra deixa um famigerado "ping 8.8.8.8"
> rolando.
> >
> > Isso tudo e você atuando lá na parte mais "foda" de lidar, o CPE.
> >
> >
> > Gosto muito mais, apesar de controverso, da abordagem com NAT um-pra-um.
> > Uma rede que tenha toda a rede em NAT um-pra-uma feita, exceto os
> > específicos(menos de 10%) vai ser muito mais simples de se migrar para
> NAT
> > muitos-para-um.
> > Eu penso que esse seria um primeiro passo elegante para se dar.
> >
> >
> >
> >
> >
> >
> >
> > Em 4 de maio de 2015 08:46, Rubens Kuhl <rubensk at gmail.com> escreveu:
> >
> > > 2015-05-04 0:06 GMT-03:00 Alexandre J. Correa (Onda) <
> > > alexandre at onda.net.br>
> > > :
> > >
> > > > Por algum tempo usamos "ON DEMAND" com IDLE de 4 horas, mas as vezes
> > > > acontecia alguma coisa que demorava mais do que o normal para
> > re-conectar
> > > > .. Cliente não esperava e já ligava na central para abrir chamado.
> Isso
> > > foi
> > > > em meados de 2006~2007...
> > > >
> > > > Pelo sim, pelo não... full-time aos que deixam ligado 24 horas....
> aqui
> > > em
> > > > casa por exemplo, 211 dias de uptime no pppoe ...
> > > >
> > > > No caso que o Rubens deu exemplo, na falta de dispositivos na LAN ele
> > > dava
> > > > um shutdown na wan... mas hoje em dia, tudo é wifi ... precisaria
> > > > implementar no WIFI também, 0 conectados.. shutdown..
> > > >
> > > > Mas eu ainda acho que isso é aumentar o índice de suporte
> > improdutivo....
> > > >
> > > >
> > > O que eu imaginei para esse controle era fazer de quando em quando
> > > requisições ARP para os IPs internos que estivessem com DHCP lease
> > válido,
> > > quer eles sejam conexão cabo ou Wi-Fi. Quem não responder fica marcado
> > como
> > > inativo... se todos os IPs internos estiverem inativos, desconectaria a
> > > WAN.
> > >
> > > Notar que isso não teria problema com acesso remoto, pois se tudo está
> > > desligado internamente, não tem o que acessar de fora (câmera por
> > exemplo).
> > >
> > >
> > > Rubens
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
>              - Osvaldo T Crispim Filho -
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>