L2TP terminated stuff should be easy enough providing the carrier lets you advertise your LNS prefixes by BGP etc.<div><br></div><div>Layer 2 hand offs could be redundant psudowires or VPLS multi-homing in theory but who is going to do that when they can bill for another EVC or specifically a VPLS service :D</div><div><br></div><div>For sites that require that level of redundancy it's probably good to build in a backup via DSL or a second EVC.</div><div><br></div>Also, having DR plans for those links in place is good too. IE have a second port on another device prepped and get remote hands to move it if there is a major failure on your side.<div><br></div><div><div><div><br>On Monday, August 17, 2015, Nathan Brookfield <<a href="mailto:Nathan.Brookfield@simtronic.com.au">Nathan.Brookfield@simtronic.com.au</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div dir="auto">
<div>Hey Mate,</div>
<div><br>
</div>
<div>
<div><span style="background-color:rgba(255,255,255,0)">Layer 3 redundancy everyone will do without to much pushing, Layer 2 no one will.</span></div>
<div><span style="background-color:rgba(255,255,255,0)"><br>
</span></div>
<div><span style="background-color:rgba(255,255,255,0)">If customers want Layer 2 redundancy they need EVC's to multiple DC's.</span></div>
<br>
Nathan Brookfield
<div>Chief Executive Officer</div>
<div><br>
</div>
<div>Simtronic Technologies Pty Ltd</div>
<div><a href="http://www.simtronic.com.au" target="_blank">http://www.simtronic.com.au</a></div>
</div>
<div><br>
On 17 Aug 2015, at 23:11, "<a href="javascript:_e(%7B%7D,'cvml','paul%2Bausnog@oxygennetworks.com.au');" target="_blank">paul+ausnog@oxygennetworks.com.au</a>" <<a href="javascript:_e(%7B%7D,'cvml','paul%2Bausnog@oxygennetworks.com.au');" target="_blank">paul+ausnog@oxygennetworks.com.au</a>> wrote:<br>
<br>
</div>
<div>


<div>
<p class="MsoNormal">HI all, just wondering what experience people have had with negotiating aggregation port redundancy/failover at different datacentres within the same state for major carriers ?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">We are looking at implementing some geographic redundancy for our layer 2 connections which are handed off on an aggregation port in one datacentre so that we have a second aggregation port in another datacentre should the carrier or ourselves
 experience a major failure like an exchange switch or something.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">We have had 2 or 3 failures over the last couple of years which luckily were on weekends and the impact was lower than normal, however the carrier does not have any interest in providing such an option across datacentres, they will do it
 within the one datacentre as long as you pay the full install and MRC on the second redundant port, but I can’t get them to do anything in separate locations.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Am I the only one who thinks that having geographic redundancy for such services is important ?<u></u><u></u></p>
<p class="MsoNormal">They don’t seem to think it’s an issue and are saying that they won’t do it but I would really like to have it for obvious reasons and am not sure if I should keep pushing or not.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I’m interested in other peoples experience in this area please.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Regards<u></u><u></u></p>
<p class="MsoNormal">Paul<u></u><u></u></p>
</div>
</div>
<div><span>_______________________________________________</span><br>
<span>AusNOG mailing list</span><br>
<span><a href="javascript:_e(%7B%7D,'cvml','AusNOG@lists.ausnog.net');" target="_blank">AusNOG@lists.ausnog.net</a></span><br>
<span><a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a></span><br>
</div>
</div>

</blockquote></div></div></div><br><br>-- <br>Regards,<br><br>Mark L. Tees<br><br>