Re: [GTER] Contratação de conexão à Internet por Metro Ethernet.

Alexandre L. Grojsgold algold at rnp.br
Wed Oct 12 12:28:29 -03 2005


>
> A qualidade depende da prestadora, não do protocolo utilizado... um
> link POS pode ter 3 falhas por ano e levar até 30h para voltar ao ar,
> por mais que os mecanismos de proteção (leia-se chaveamento para
> circuito alternativo em caso de falha) de POS estejam bem
> estabelecidos há mais tempo e permitam recuperar uma falha em 50ms.


Exatamente, um procedimento de redundância nunca é melhor do que os
equipamentos que os implementam.

De nada adianta ter 50 rotas alternativas se frequentemente os
equipamentos que deveriam chavear entre as rotas falham miseravelmente.


>
> Para uma mesma qualidade construtiva e de processos de serviço, as
> diferenças mais significativas entre Ethernet e POS me parecem:
> 1) POS tem mecanismos de proteção já padronizados e estabelecidos, e
> de performance bastante boa (50ms). Caso haja proteção entre circuitos
> Ethernet primário e secundários, como se dá, e com que velocidade de
> chaveamento ? Dá para fazer por MPLS Fast Reroute, Spanning Tree
> convencional, Rapid Spannig Tree, RPR (apesar de que não seria
> exatamente Ethernet neste caso) ou <insira aqui algo do Metro Ethernet
> Forum>.


Confesso que eu nunca entendi bem a vantagem da recuperação em 50 ms, em
oposição a uma recuperação em, digamos, um tempo 10 vezes maior (500 ms).


Dado que esses episódios não acontecem todos os dias, que diferença me faz
se chaveia-se em 50ms, 500ms ou mesmo 5 segundos?

O que mata são os episódios de não chavemento, quando fica-se fora do ar
50 segundo, 5 minutos, até 5 horas !!


Eu prefiro 50 vezes mais uma tecnologia que chaveie com 99,999% de certeza
em 5 segundos a uma que *em geral* chaveie em 50ms.

Nesse aspecto, qual a melhor: metro ether ou SDH? Não sei.



> 2) POS com PPP ou HDLC tem controle de keep-alive do circuito... em
> Ethernet convencional, não se sabe quando algo caiu. Assim, se não
> houver um protocolo dinâmico de roteamento para perceber a queda do
> link, você não vai saber que ele caiu (a não ser que a perda de
> potência óptica seja muito evidente)... mesmo para situações de rota
> única para a Internet, acho interessante ter BGP nesse circuito. Mesmo
> que seja com a operadora anunciando só a rota default, o cliente não
> anunciando nada, e o protocolo estando lá só para te dizer se o link
> está no ar. Spanning tree daria essa mesma visibilidade, em L2, para
> circuitos redundantes.


Esse é um problema.

Outro problema que vejo é o da banda limitada.

Normalmente o provedor fornece uma porta Ether 100, mas limitando a banda
a um determinado valor.  Essa limitação é feita descartando frames que
excedam ao bit rate contratado.

Isso funciona, decerto, os aplicativos IP se adaptam. Mas ter uma
estrutura nível 2, entre dois routers, que faz sumir pacotes magicamente
em pleno voo certamente não ajuda o router a tomar atitudes razoáveis face
a congestionamentos ou momentos de uso muito intenso.

Certo?


-- Alexandre.




More information about the gter mailing list