[GTER] Borda ideal para provedores

[Felipe Trevisan]

Shine, Vamos discutir o assunto a exaustão. Essa é uma oportunidade de
aprendizado para mim também.
Eu nao sou um tecnico de redes. Conheço um pouco e consigo ir até certo
ponto. A partir dali preciso pedir ajuda aos universitarios. Peço paciencia
caso não consiga responder de pronto todas as questoes.
ᐧ



2014-05-08 20:38 GMT-03:00 Shine <eshine at gmail.com>:

> Oi Felipe,
>
> Obrigado pela paciência em discutir o assunto.
> A minha participação aqui é puramente técnica, sem nenhum interesse ou
> vínculo comercial. Eu não trabalho nesta área, o intuito é mesmo trazer
> mais detalhes para me atualizar tecnologicamente.
>
> Ainda tenho mais dúvidas, se você puder esclarecer para nós da comunidade
> agradeço...
> >
> Desculpe eu não fui claro... estava falando de ter um opex para o provedor
> de serviços.
> Ele vai ter que ter um procedimento operacional para cuidar da gestão da
> rede, de registrar o cliente, de correlacionar o cliente dele com o serviço
> prestado pelo provedor de rede.
> Sei que não é relacionado diretamente com a sua estrutura, mas imagino que
> seja um desafio operacional para o provedor de serviço.
>
> Esta dificuldade que vc menciona não é maior do que a enfrentado por
muitos provedores atualmente. Como se provisiona um novo cliente? O mesmo
processo pode ser replicado. Grande parte é automatizado.

No momento que o provedor inicia seu relacionamento com o provedor de rede,
ele define os produtos que vai oferecer, as velocidades e demais
caracteristicas técnicas de cada um dos serviços. Define tambem valores
para cobrar do cliente final, os textos que aparecem no site, o link para
seu contrato de prestação de serviços, etc. Estes ultimos podem ser
alterados pelo ISP livremente a qualquer tempo.
Quando o cliente escolhe um determinado serviço daquele provedor, o sitema
faz as associações automaticamente. No final do periodo o sistema emite um
relatorio da quantidade de clientes em cada serviço e os valores que devem
ser cobrados.

Não tenho certeza se esclareci sua dúvida.


> > Normalmente quem opera o DHCP é o provedor. O cliente passa pela rede do
> > provedor de rede de forma transparente até os roteadores do ISP. Esta
> > estrutura do ISP que gerou a duvida inicial desse thread.
> > Existe uma opção no sistema para o provedor cadastrar seu bloco de IP
> para
> > cada tipo de serviço e o sistema do do "operador do unbundling"
> administra
> > e mantem os logs. Não é comumente usado mas daria para ser feito.
> >
> Na verdade se o DHCP passa transparente, o provedor de serviço tem que ter
> um servidor DHCP na VLAN correspondente. Esse design tem alguns desafios
> que precisam ser pensados, só para citar alguns:
> 1) como restringir o acesso de vários clientes na mesma vlan? Claro que em
> termos de velocidade ele já se provisiona, mas vamos pensar que a conexão
> na vlan pode ter um bridging no cliente e ele pode ver vários dispositivos.
> Como o provedor de serviços vai diferencial por qual circuito passa cada
> cliente, como ele vai fazer o dimensionamento de pool? Existem alternativas
> como relay e option 82, mas é em cima de rede roteada e aí tem implicação
> de estrutura de camada 3.
> 2) como evitar um rogue DHCP na rede?
> 3) como evitar que um usuário use IP fixo e gere problemas de duplicação na
> rede?
>
>
1) A configuração de cada serviço é pré-configurada também através de
service profiles (eu atualizei aquele ppt e isneri a imagem da configuracao
de um service profile). Nele vc limita a quantidade de ip´s permitidos.
Confesso que estamos no limiar do que consigo responder tecnicamente e
talvez precise pedir ajuda.
As informações do option 82 podem ser repassados ao ISP.
2) Na VLAN dedicada ao provedor só vai haver o DHCP dele. As restrições são
normalmente bloqueadas na porta do switch onde o cliente está conectado.
3) Não é o provedor que aloca o IP fixo do cliente? Ele teria de controlar
de alguma forma.





>    - Eu tenho mais dúvidas ainda. Como acoplar a rede dos provedores?
> >       - O provedor tem um ou mais pontos de interconexao com os
> >       equipamentos do provedor de rede. Pode ser feito através do PTT
> > inclusive.
> >
> Bom, assumindo que ele recebe uma rede camada 2 do cliente diretamente,
> acho que não dá para usar PTT não... com a palavra os mestres da lista.
>
> Q-in-Q? O PTT pode entregar cada provedor em uma porta do PIX. Este é
conectado ao switch de interconexão normalmente. Tanto faz se o ISP esta no
rack do lado ou através do PTT.



>
> >       - Porque haveria redundancia entre os provedores? O provedor deve
> >       manter seus equipamentos funcionando. Pode optar por se
> > interconectar em
> >       mais de um ponto, mas a interconexao entre estes dois pontos do ISP
> > é de
> >       responsabilidade dele.
> >
> Você confiaria em uma única conexão entre o provedor de serviço e o
> provedor de rede? Manter equipamento funcionando é obrigação, claro, mas
> acho que o cliente não vai esperar reparar um equipamento de core ou uma
> fibra que interliga o provedor de serviço e o provedor de rede...
>
> Não, nao confiaria em uma unica conexao. O provedor deve ter duas
interconexoes. O provedor de rede disponibiliza as duas portas, seja no
mesmo local ou em locais alternativos. Isso sim se parece com o PTT. O
provedor pode chegar em dois PEX e pedir duas portas, uma em cada um. O
modo de chegar em cada PIX é de responsabilidade do provedor.





>
> >       - Essa duvida faz parte da duvida inicial de como montar a borda
> >       ideal. Este é um problema para o ISP resolver que eu estou querendo
> > saber
> >       como fazer tambem. O provedor de rede vai dar o tubo, a mágica é
> > com o ISP.
> >
> Acho que entendi o modelo, mas ele traz uma série de desafios técnicos ao
> provedor de serviços.
>
>
Não entendo porque. O que muda em relação ao que ele faz? Como deveria ser
entregue a conexao do provedor de rede para minimizar o trabalho do ISP?



>       - Voce pode me envair as duvidas, ou entao marcamos um call.
> >
> Sem call... a dúvida não é para mim, mas para a comunidade. ;)
>

:-)


>
>
> > *Se houver problemas na rede de acesso.
> >       - Atualmente, se seu provedor te deixar na mao, vc liga no noc
> dele e
> >       abre um chamado, depois acompanha o ticket.
> >       - Aqui vc vai acompanhar o ticket sem precisar abrir o chamado,
> pois
> >       voce terá acesso direto na mesma base de informação que o
> > responsavel por
> >       arrumar a rede (supondo que seja um problema de rede).
> >
> Mas operacionalmente o provedor de serviços precisaria de um staff técnico
> de alta qualificação para poder acompanhar o problema... no final isso gera
> mais custo para o provedor de serviço.
>

De novo, o provedor já não tem este tipo de pessoal em seus quadros?



>
>       - Nao tem filtro. A informacao trocada entre o provedor de serviços,
> >       o operador do unbundling e o prorietario de rede é vista por todos.
> > Todos
> >       ficam ao par do que ocorre. Um novo tipo de relacionamento.
> >
> Isso se ambos entendem as informações... o que eu não contaria como certo.
>
>
Bom, eu nao estava considerando isso como um problema. Talvez esta seja um
dos pré-requisitos para o ISP poder particpar da rede.


>
>
> >       - O ticket vai conter as informacoes. Elas sao enviadas pelas
> equipes
> >       responsaveis. O coordenador das equipes de campo pode alimentar o
> > sistema.
> >       - Tem razão. A experiencia mostra que a maior parte dos problemas
> são
> >       resolvidos pelo atendimento nivel 1 dado pelo proprio ISP quando
> > o cliente
> >       liga. O ISP nem abre o ticket no sistema compartilhado pois
> > resolve dentro
> >       de casa.
> >       - Caso efetue todos os testes e não consiga resolver dentro de sua
> >       estrutra, o ISP abre um ticket na plataforma e imediatamente é
> visto
> > por
> >       outros envolvidos.
> >
> A idéia de deixar a plataforma aberta ao provedor de serviços é
> interessante, mas isso demanda ter staff técnico adequado. E isso tem
> custo.
>

A condição para o sistema funcionar é justamente estar aberta ao provedor.
Não tem como ser diferente. Por isso o sistema foi criado em torno disso.
Deve ser esta a duvida com relação ao alto acoplamento que o Rubens
mencionou. Estou certo?



>
>
> >    - O modelo seria por tempo de serviço ou por quantidade de dados?
> >       - Este é um controle do ISP. O uso da rede é por usuario/por
> >       serviço/por velocidade.
> >       - Exemplo: um tubo de 100 Mb poderia custar 100 reais, o de 200Mb
> 200
> >       reais. IPTV adiciona mais 20, VOIP adiciona mais 5.
> >
> OK, simples. Mas dizendo que ele altere a velocidade por demanda do
> usuário, isso precisa ter um sistema CRM bem sincronizado, fora um sistema
> de auditoria... não me parece simples para o provedor de serviço, mas acho
> que os colegas da lista estão mais atualizados do que eu... quem sabe
> alguém escreve um artigo me dizendo o que evoluiu nesses anos...
>

O CRM e a auditoria fazem parte do sistema do provedor de rede, sem isso
nada funcionaria.
No sistema estao concentrados os dados do cliente, endereços, serviços,
provedores e todo o historico de contratacoes, cancelamentos, upgrades e
trocas. Informacoes de ativações, bloqueios pro falta de pagamento,
liberacao apos pagamento ter sido efetuado, mudanças de endereços, enfim,
tudo concentrado na plataforma.




>
>
> >       - Como o sistema faria a auditoria de uso?
> >       - O sistema é todo auditável. O provedor de rede somente monitora o
> >       trafego das portas e se elas estao de pé. Garante que não haja
> > gargalos
> >       entre os nós, fazendo os upgrades neessários quando a capacidade
> > demandar.
> >    - Como seria a qualificação da qualidade de serviço, como seria a
> tomada
> >    de métrica do serviço?
> >       - Pode haver uma configuracao geral dizendoq ue VLANs de voz tem
> >       prioridade sobre as de dados dedicados, que tem prioridade sobre as
> > de
> >       dados compartilhados. Este tipo de filtro só é ativado se houver
> > gargalo. A
> >       idéia é que não haja gargalos.
> >    - Coisas como jitter, latência, taxa efetiva de transferência de dados
> >       - Mesmo caso da resposta acima.
>
> Então suponho que o provedor de serviço tenha acesso a uma ferramenta do
> sistema que emula uma consulta SNMP nas portas e somente nas portas que ele
> locou com o provedor de rede? E como isso é feito? O sistema emula um
> serviço SNMP no espaço de gerência onde somente as portas locadas para o
> provedor estão conectadas em tempo real?
>

Cada cliente esta conectado a uma porta. O procedimento é simples:

ISP acessa o sistema
Busca o cliente
No Overview do cliente ele verá a porta e o switch onde o cliente esta
conectado.
Clicou no icone, o sistema faz uma consulta em tempo real ao switch e busca
as informacoes. Vc fica sabendo na hora se a porta esta admin up, e com o
cabo conectado, qual vlan, modo trunk ou access, trafego acumulado. Se ele
estiver com DHCP ativado, ja ve o ip alocado ao cliente o mac address
resolvido do que estiver conectado na ponta.
Dependendo do switch, vc consegue fazer aquele teste para saber o estado
dos cabos utp ou das fibras.
O sistema mantem um grafico MRTG de cada porta ativa. Nesta mesma tela, o
ISP poderia clicar e enxergar os graficos de consumo da porta, por dia,
semana, mes e ano.

Existem algumas CPE homologadas. Se o cliente estiver conectado através de
uma CPE, o ISP enxerga o CPE e todas as suas portas. Vai saber por exemplo
qual VLAN esta associada em cada porta do switch, qual esta com cabo
conectado, quais linhas de telefone estao associados a portas SIP,
controlar o SSID e ativar, desativar SSID´s remotamente.




Abs,




> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>