[GTER] MPLS vs outras. Era: Edgerouter-8

[Rodrigo Corte]

O Tempo de convergencia do MPLS só será mais rápido se usar RSVP ao invés
de LDP. Usando LDP a convergência do RSVP fica determinada pelos tempos do
OSPF sendo esse mais lento que RSTP.



Att;

rc.

-- 





On 04/02/15 18:05, "Felipe Trevisan" <fetrevisan at gmail.com> wrote:

>E aquela historia de o tempo de convergencia em MPLs ser muito menor que o
>RSTP, e também a questão de não acontecer loops em redes MPLS?
>
>
>
>2015-02-04 15:40 GMT-02:00 Marcos Tadeu <marcos at telecom.uff.br>:
>
>> +1, Rubens
>> Exatamente como se faz a nuvem backup da nuvem MPLS: toda em VPN
>> criptografada com certificados x509, em cima de links com operadoras
>> locais: viva os pequenos locais ! E o resultado é SLA mensal de
>>100,0000%,
>> medido.
>> Em geral, como a arquitetura em estrela impera, muitos acabam em simples
>> rota estática pela VPN.
>> Um OSPF vai bem, e os viciados em BGP também são bem vindos.
>>
>> Poucos são os que tem dois ou três "nós centrais". Normalmente um deles
>>é
>> standby para fins de DR.
>>
>> Então, MPLS para o cliente final é um "tanto faz";
>> E apelo do QoS na MPLS? Vejo poucas empresas usarem descentemente as
>> diversas classes AF disponíveis. E, dos que tentam dividir a banda e
>> classificar, uma parcela menor ainda monitora as classes AF, o que
>>passa o
>> que falta de banda em cada uma etc, por exemplo, assim, com um mundo
>>mais
>> colorido e gráfico negativo para download:
>>
>>
>> OPA caiu o link central no data center!!! Num horário bom para acabar
>>com
>> os negócios.
>>
>> Ninguém viu/sentiu, graças às operadoras locais, foi tudo pela VPN
>>
>>
>>
>> E ainda usa a VPN para tráfegos pesados, como downloads pesados, etc...
>>
>> On 02/04/2015 05:37 AM, Rubens Kuhl wrote:
>>
>>> 2015-02-04 1:00 GMT-02:00 Douglas Fischer <fischerdouglas at gmail.com>:
>>>
>>>  " Com o protocolo que roda em todos eles, IP..."
>>>>
>>>> E o overlap do endereçamento dos clientes?
>>>> Vai sair mapeando VRF de cada cliente de caixa em caixa?
>>>> Mesmo que o cliente não tenha presença naquela caixa?
>>>>
>>>>  Não, tunelamento IPIP, GRE, IPSEC com null chipher, PPTP, L2TP, PWE
>>>>ou
>>> qualquer um que se prefira por qualquer motivo.
>>>
>>>
>>>
>>>> " O que é usado no backbone não significa que não se faça uma oferta
>>>> diferente pro cliente, baseada em recursos dos CPEs. Por exemplo, por
>>>> mais
>>>> que eu ache que contratar VPN L2 faça muito mais sentido para clientes
>>>> por
>>>> causa de independência para mudar roteamento, um cliente pode
>>>>contratar
>>>> VPN
>>>> L3 e isso ser prestado em cima de um backbone que não sabe o que é
>>>>MPLS "
>>>>
>>>> Sim mas isso depende da operadora confiar no CPE para entregar o "o
>>>>que"
>>>> da
>>>> forma certa.
>>>> Inclusive a ponto de, dependendo da config do CPE, um cliente acabar
>>>> entrando na nuvem do outro(caso extremo).
>>>> E para mim o "C" do CPE diz de quem deve ser a autoridade do
>>>>equipamento.
>>>>
>>>>  Não, não diz. O "P" do CPE diz que fica nas instalações do cliente,
>>>>mas
>>> não
>>> sobre autoridade do cliente. Não há projeto de rede MPLS sem um CPE
>>>(ou o
>>> nome que você preferir) sob controle da operadora instalado na unidade
>>>ou
>>> matriz do cliente, pois não há segurança suficiente em MPLS para se
>>> extender a rede com labels até o cliente (e aí sim qualquer um poder
>>> trocar
>>> label e bypassar segurança). Na nomenclatura MPLS, é um equipamento
>>>CE. O
>>> primeiro equipamento que coloca um label MPLS é o PE, e fica já na
>>> operadora.
>>>
>>> Se mesmo as VPNs MPLS entregues por aí dependem de  um CE para fazer a
>>> função correta, o mesmo pode ser feito um CPE que faça algum
>>> encapsulamento
>>> para IP. E o tipo pode ajudar a garantir o isolamento da rede do
>>>cliente,
>>> notadamente com criptografia e ACLs.
>>>
>>>
>>> Rubens
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>--
>gter list    https://eng.registro.br/mailman/listinfo/gter