[f-nsp] MPLS feasibility

Frank Suter frnkstr at gmail.com
Mon Sep 6 10:36:24 EDT 2010


Hello Heath,

Thanks for your input.

Yes this is a LAN extension and I am obviously going to discuss this with a
proper consultant, but there are not millions of them around here so I am
trying to touch base here so I can brief accurately my ISP/integrator about
what I want to achieve and make sure it is possible.

I might be asking one of my ISPs to do the redundancy and implementation for
me, as they are more or less neutral with this, but I know that if I would
ask my ISP about redundancy, they would be offering me a "protected" ring on
their network, which would be like a waste of money for me from past
experience. Usually when things goes wrong, they go totally wrong and I have
already seen two carriers going down together for physical path damage
although they were not supposed to share it.

Based on the facts, I know that in the building there are two different
carriers that bring each their own FO. They are competitors and hate each
other and will never work together, which is good for me. Each of them makes
us of a different physical path to reach the end-point for legacy reasons. I
am quite confident about both being able to deliver this service with an RTT
of 3 ms maximum.

I am thinking about all options possible here. I am thinking about having
for instance one of the MPLS line dedicated for voice and the other one
dedicated for the data with a pre-configured QoS, so that I can have a
fail-over mechanism in case of worst event without risk of hours and hours
of downtime in worst case scenario.

Once again, thank you Heath.

Frank


2010/9/4 Heath Jones <hj1980 at gmail.com>

> Hi Frank,
>
> Are you talking about an lan extension service / pseudowires / vpls / etc
> ie. Ethernet that the carriers are tunneling over MPLS?
> If that is the case, it should be delivered as a simple ethernet circuit to
> you. Of course you can do load balancing over 2 ethernet links, you can play
> with metrics and have redundancy too. You cannot have both though obviously
> (if you use >100Mb/s). Something to consider if you are load balancing like
> this: the circuits will have different latency and packets *will* get out of
> order.
>
> The best advice however is you should contract a consultant or a company to
> fully understand what you want to achieve and give you case specific
> guidance.
>
> If everyone in your situation got free 'professional services' on these
> forums, we would all be out of jobs! :)
>
>
> Best of luck
> Heath
>
>
>
> On 4 September 2010 20:15, Frank Suter <frnkstr at gmail.com> wrote:
>
>> Dear all,
>>
>> I am writing to this list, because I am using Brocade/Foundry routers and
>> switches. This is maybe not the most accurate list, if so, please accept my
>> apologies.
>>
>> Here is the context: I am currently having a datacenter presence where I
>> do run my own AS with three ISPs, each with full BGP table and a /23 PI
>> dedicated to the servers and Internet access. Because this is considered as
>> the consolidated Internet access and datacenter, I would like to hub the
>> office with this connection.
>>
>> Now my goal is to connect the office with the datacenter using a symmetric
>> 100/100 Mbit link running MPLS service from my ISP. This will be delivered
>> as a service. Now, because redundancy is important for me, I would link to
>> have a second link 100/100 Mbit, but rather than asking the same provider to
>> secure the path, I would like to ask this to a second provider because I do
>> not trust one provider to do redundancy for me.
>>
>> I know that each provider are using physical different path to reach the
>> Data Center.
>>
>> Questions:
>>
>> 1) Can I build a redundant MPLS access with two different providers and
>> aggregate them together on each end? Thus having two paths of 100 Mbit
>> symmetric each. Possible?
>> 2) What equipment do I need on the office side to do this?
>> 3) How long is the convergence time to expect in case of major failure on
>> one of the links?
>>
>> Thank you for your time and advices.
>>
>> Frank
>>
>>
>> _______________________________________________
>> foundry-nsp mailing list
>>
>> foundry-nsp at puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20100906/fb6343f6/attachment.html>


More information about the foundry-nsp mailing list