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 <[email protected]> > 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 <[email protected]> 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 >> >> [email protected] >> http://puck.nether.net/mailman/listinfo/foundry-nsp >> > >
_______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
